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PRÓLOGO A LA EDICIÓN ESPAÑOLA 


Al final de los años ochenta el mundo de la informática se estructuraba en 
un núcleo industrial operativo (informática de bancos y grandes empresas) 
rodeado de un puzzle de nuevas tecnologías emergentes que buscaban un 
reconocimiento por su valor tecnológico y utilidad. Este reconocimiento 
debía tomar la forma de aplicaciones en la vida real que les dieran el lugar 
que creían merecer en la informática y en la bistoria. 

Por un lado teníamos Internet, la gran Red que había conseguido in- 
tegrar redes más pequeñas y se iba convirtiendo rápidamente en un vebí- 
culo internacional de comunicación. Entre sus principales precursores 
aparecieron figuras como Vinton Cerf, uno de sus creadores, o Larry 
Landweber, su principal profeta y evangelista internacional, hombres 
que —entre otros— terminarían creando la Internet Society, primera or- 
ganización que se ocuparía oficialmente de promocionar el desarrollo y 
uso de esta Red, dando un cobijo formal al IETE cuerpo de ingenieros 
de Internet, y a LANA, su corazón coordinador y operativo. Internet era, 
sin embargo, una red para especialistas con conocimientos de informáti- 
ca más bien altos. Encontrar algo en Internet requería conocer bien sus 
mecanismos, así como el formato y la localización exacta de lo que buscá- 
bamos. 

Mientras Internet se mantenía funcionando en un ambiente infor- 
mático poco amigable, los ordenadores personales iban integrando no 
sólo los nuevos dispositivos que facilitaban el uso del ordenador (como 
el ratón), sino también entornos gráficos e intuitivos. El sistema que 
marcó la diferencia fue sin duda el de Macintosh, una evolución de los 
desarrollos de Xerox que sería utilizado como modelo en los entornos de 
Next y Microsoft. 


Javier Solá es Director de la Asociación de Usuarios de Internet y ha sido Vicepresi- 
dente de la Internet Society. 
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La tercera tecnología que empezaba a funcionar era'el hipertexto, 
una idea que integraba el sentido gráfico de los nuevos desarrollos con la 
posibilidad de crear textos distribuidos. Estos textos incluirían referen- 
cias que no estuvieran directamente en el texto, pero a las que se pudiera 
acceder inmediatamente mediante un sencillo click de ratón. Este siste- 
ma de acceso requería una nueva forma de estructurar la información en 
unidades o páginas interrelacionadas. Cada página era una unidad de in- 
formación, pero se encontraba vinculada a todas las demás páginas que 
contuvieran información relacionada con o mencionada en esa página. 

Por último, la tecnología reinante durante los años ochenta fue la In- 
teligencia Artificial. La LA no sólo era una gran esperanza de la industria 
punta, sino también el caballo de batalla de los fabricantes de ordenado- 
res, su forma de demostrar que estaban en la cresta de la ola y que eran la 
compañía con la que se debía trabajar. Desgraciadamente, la LA fracasó 
estrepitosamente al final de los ochenta. Pocas fueron las aplicaciones 
que realmente llegaron a funcionar, a pesar de las grandes cantidades de 
dinero que fabricantes y clientes habían invertido. En mi humilde opi- 
nión la causa de este fracaso fue la imposibilidad de reflejar al 100% en. 
un ordenador el conocimiento de expertos en diferentes temas. La reali-' 
dad con la que nos encontramos fue que el 90% del conocimiento era 
poco más útil que el 0%, ya que el sistema resultante no podía en nin- 

- gún caso reemplazar el trabajo del experto. 

Por su parte, Internet ya había revolucionado la ona de investigar 
y de producir estándares. La organización encargada de producir están- 
dares en el mundo de las telecomunicaciones era la Unión Internacional 
de las Telecomunicaciones (International Telecommuntcations Union, 
ITO), una organización de tratado bajo el paraguas de la ONU. La ITU 
es una organización sólida que ha producido importantes estándares en 
telefonía y el centro de acuerdo con que cuentan los estados en lo refe- 
rente a comunicaciones. Su gran problema es y era su lentitud. Conse- 
guir acuerdos con los países firmantes es un proceso arduo y lento, por lo 
que el desarrollo de estándares era un proceso interminable. 

Los desarrolladores de Internet se encontraron con que la velocidad 
a la que era necesario desarrollar los estándares no era compatible con 
los tiempos requeridos por la ITU. Por otro lado, los protocolos de Inter- 
net no tenían necesidad de ser aprobados por ningún Estado, ya que 
eran acuerdos entre aquellas personas y empresas que estaban mejoran- 
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do y haciendo crecer la Red. Una decisión histórica puso en marcha el 
IETF (Internet Engineering Task Force) un foro de desarrollo de están- 
dares y protocolos para Internet autogestionado, en el que cualquiera in- 
teresado en un tema podía participar en las reuniones y en las decisiones. 
Este modelo resultó ser perfecto para Internet, ya que las personas que 
estaban interesadas en un estándar o protocolo participaban en su crea- 
ción, pruebas, control, etc... Con el tiempo el IETF fue formalizando sus 
procedimientos, convirtiéndose en una verdadera máquina de producir 
avances en Internet, 

Es irónico que Tim Berners-Lee, al acudir al IETF para desarrollar 
los estándares del Web, lo encontrara demasiado lento para lo que le in- 
teresaba. Este problema manifiesta el cambio de velocidad que tuvo lu- 
gar en Internet ya a principios de los noventa, y que le llevaría a la crea- 
ción de un nuevo cuerpo de creación de estándares y protocolos, el World 
Wide Web Consortium (W3C). 

La genialidad de Berners-Lee no estuvo en inventar algo nuevo, sino 
en saber unir las piezas tecnológicas que existían en un momento deter- 
minado para crear algo infinitamente más grande que lo que cada una de 
estas piezas podía significar por separado. La unión de Internet con el bi- 
pertexto —de la que fue creador y evangelizador— fue la semilla a la 
que otros fueron añadiendo piezas (como los gráficos que Andreessen in- 
cluyó en el navegador “Mosaic” o nuevos lenguajes como Java o XML) 
para llegar a lo que hoy es el World Wide Web, una mezcla de formatos 
de datos interrelacionados a los que un usuario puede acceder sin tener 
que preocuparse del formato de un documento... o sencillamente sin sa- 
ber lo que es un formato, solamente sabiendo utilizar un navegador, algo 
que no se tarda más de una hora en aprender. 

El resultado no es interesante porque sea técnicamente superior a lo 
existente, sino porque ha conseguido dar a Internet un tipo de interfase 
que cualquier nuevo usuario puede utilizar con pocos minutos de forma- 
ción, convirtiendo la Red en una verdadera herramienta de usuario fi- 
nal. Esta posibilidad ha animado a cientos de miles de compañías e in- 
dividuos a poner información en Internet, creando —en muy poco 
tiempo— una masa crítica que hace interesante a prácticamente cual- 
quier persona el conectarse a la Red. 

En este libro Tim Berners-Lee habla no sólo de su historia sino tam- 
bién de lo que él ve en el futuro de la informática y de las telecomunica- 
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ciones. Su interés en añadir valor al Web le lleva a intentar incluir en la 
Red la mayor cantidad de inteligencia posible. Esta inteligencia, no tan 
ambiciosa como la de Inteligencia Artificial, empieza con cosas pequeñas 
y prácticas, como negociar el nivel de privacidad que un usuario requiere 
de los sitios web que visita o á los que da sus datos, pero deja abierto el 
camino bacía nuevas aplicaciones más potentes. 

Como veremos en este libro, el W3C ba demostrado la importancia 
que tienen los estándares en el desarrollo de la tecnología y de la socie- 
dad. PICS, uno de los resultados del W3C, fue una de las claves para de- 
mostrar en EE UU que existía la tecnología en Internet para proteger a 
la infancia, y así echar abajo la Telecommunications Decency Act del 96, 
una ley que permitía una censura activa de Internet. 

Abora Tim Berners-Lee trabaja para el futuro, y para él el futuro es 
crear las herramientas que permitan añadir inteligencia a Internet. Crear 
los formatos de datos y estándares que den a la información una estruc- 
tura que pueda ser utilizada por otros para crear procesos deductivos 
que bagan la experiencia del uso de Internet más interesante. Una vez 
más Berners-Lee va por delante de la sociedad, eliminando barreras al 
desarrollo del World Wide Web e intentando crear una red que permita 
mejorar la comunicación entre los seres humanos. 


Javier SOLÁ MARTÍ 
Director de la Asociación 
de Usuarios de Internet 
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PREFACIO 


Tejiendo la Red es una historia Única acerca de una innovación única 
hecha por un inventor único. 

Entre la gran cantidad de información existente acerca del World 
Wide Web destaca una historia, la de la creación y posterior evolución 
de esta increíble cosa nueva que está apareciendo para abarcar el 
mundo y convertirse en una parte importante y permanente de nues- 
tra historia. Este relato es único porque está escrito por Tim Berners- 
Lee, que creó el Web y está conduciéndolo ahora hacia nuevas direc- 
ciones emocionantes. Ningún otro puede decir lo mismo. Y ningún 
otro puede escribir esto: la auténtica historia del Web. 

La innovación de Tim también es única. Ya nos ha proporcionado 
un gigantesco Mercado de Información, en el que individuos y organi- 
zaciones compran, venden e intercambian libremente información y 
servicios de información entre sí. La prensa, la radio y la televisión nun- 
ca se acercaron tanto; lo único que pueden hacer es llevar la misma in- 
formación procedente de una sola fuente hacia muchos destinos distin- 
tos. Tampoco la carta o el teléfono pueden aproximarse al poder del 
Web, porque incluso aunque estos medios permitan los intercambios 
entre dos, son lentos y carecen de la capacidad del ordenador para mos- 
trar, buscar, automatizar y transmitir. Notablemente —en comparación 
con la imprenta de Gutenberg, el teléfono de Bell y la radio de Marco- 
ni— y mucho antes de alcanzar su forma definitiva, el Web de Berners- 
Lee ya ha dejado bien establecida su condición de única. 

Miles de científicos informáticos han estado contemplando duran- 
te dos décadas las mismas dos cosas: el hipertexto y las redes informá- 
ticas. Pero sólo Tim concibió la manera de unir estos dos elementos 
para crear el Web. ¿Qué forma de pensar diferente le condujo a esto? 
No hay duda que la misma forma de pensar que veo hoy, y que le con- 
duce a él y al equipo del Consorcio World Wide Web que él dirige a 
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luchar para definir el Web del futuro. Mientras el resto del mundo re- 
pite alegremente el mantra del comercio electrónico, él está pensando 
en el Web como un medio que codifique, por medio de sus vínculos 
de información gigantescamente distribuidos, el conocimiento y la 
comprensión humanos. 

Cuando conocí a Tim, me sorprendió otro rasgo suyo único. 
Mientras los técnicos y los empresarios lanzaban o fusionaban compa- 
ñías para explotar el Web, parecían fijarse sólo en una cuestión: 
“¿Cómo puedo hacer mío el Web?”. Mientras tanto, Tim pregunta- 
ba: “¿Cómo puedo hacer vuestro el Web?”. Cuando él y yo empeza- 
mos a preparar su llegada al Laboratorio de Ciencias Informáticas del 
MIT y el lanzamiento del Consorcio del World Wide Web, su objetivo 
permanente era asegurarse de que el Web avanzase, floreciese y pet- 
maneciera íntegro, a pesar de los tiras y aflojas de todas las empresas 
que parecían querer controlarlo. Seis años más tarde, el punto de mira 
de Tim señala exactamente en la misma dirección. Ha dicho en repeti- 
das ocasiones “no” a todo tipo de oportunidades seductoras si éstas 
amenazaban, al final, la independencia y la integridad del Web, y si- 
gue siendo altruista y fiel a su sueño. Estoy convencido de que lo hace 
no sólo como un deseo de asegurar el futuro del Web, sino como una 
muestra de integridad que encuentro más impresionante que sus proe- 
zas técnicas. 

Cuando sugerí a Tim por primera vez que escribiera este libro, y 
habiendo acabado uno yo mismo recientemente, tenía en mente una 
serie de libros del Laboratorio de Ciencias Informáticas del MIT 
(LCS) en los que hablaríamos en lenguaje accesible de nuestras inno- 
vaciones y de su impacto social, Mucha gente en el mundo cree que la 
tecnología nos está deshumanizando. En el LCS creemos que la tecno- 
logía es hija inseparable de la humanidad y que para llevar a cabo un 
auténtico progreso, las dos deben ir de la mano, sin que ninguna de las 
dos actúe como sirviente de la otra. Pensé que sería importante e inte- 
resante que el mundo conociera a la gente que crea nuestro futuro y 
no a futurólogos secundarios; especialmente cuando estos innovado- 
res están dispuestos a exponer sus capacidades técnicas y sueños so- 
cialitarios que les condujeron hasta sus creaciones. Tim se ha enfrenta- 
do a este desafío de forma admirable, exponiendo sus profundas 
creencias acerca de cómo puede evolucionar y dar forma a nuestra so- 
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ciedad el Web en formas que son nuevas y difieren profundamente de 
la sabiduría popular. 

En Tejiendo la Red, Tim Berners-Lee va más allá de limitarse a 
contar la irresistible historia del Web: abre una ventana al modo en 
que una persona única inventa y alimenta un punto de vista único que 
altera el curso de la humanidad. 


Michael L. DERTOUZOS 


Director del MIT Laboratory for Computer Science 
y autor del libro What Will Be 


1. PREGUNTAR EN EL INTERIOR ACERCA 
DE CUALQUIER COSA 


Cuando empecé a enredar por primera vez con un programa de soft- 
ware que pudiera llegar a dar forma al World Wide Web, lo llamé En- 
quire, abreviatura de Enquire Within upon Everything [Preguntar en el 
interior acerca de cualquier cosa], título de un viejo libro victoriano de 
consejos que vi de niño en casa de mis padres, cerca de Londres. Con 
su sugestivo título mágico, el libro servía como portal a un mundo de 
información acerca de todo, desde cómo quitar manchas de la ropa 
hasta consejos para invertir dinero. No era una analogía perfecta del 
Web, sino un punto de partida primitivo. 

A lo que ese primer atisbo del código de Enquire me condujo fue a 
algo mucho mayor, una visión que abarcaba un crecimiento de ideas, 
tecnología y sociedad orgánico y descentralizado. La visión del Web 
que tuve fue la de cualquier cosa potencialmente conectada a cual- 
quier cosa. Es una visión que nos proporciona una nueva libertad y 
nos permite crecer más rápidamente de lo que nunca pudimos crecer 
cuando estábamos encadenados por los sistemas de clasificación jerár- 
quica a los que nos aferramos. Deja la totalidad de modos de trabajar 
anteriores como sólo una herramienta entre muchas. Deja los miedos 
que teníamos al futuro convertidos en uno entre muchos. Y acerca 
más los funcionamientos de la sociedad a los funcionamientos de 
nuestra mente. 

Contrariamente a Preguntar en el interior acerca de cualquier cosa, 
el Web que he tratado de fomentar no es solamente una mina de in- 
formación que haya de ser excavada, ni es tampoco una referencia ni 
una herramienta de investigación. A pesar del hecho de que los ahora 
omnipresentes World Wide Web y .cor impulsen el comercio electró- 
nico y los mercados bursátiles en todo el mundo, ésta es una gran 
parte, pero sólo una, del Web. Comprar libros en Amazon.com y ac- 
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ciones en E-trade no es lo único que hay en el Web. Tampoco es el 
Web una especie de espacio idealizado en el que podemos quitarnos 
los zapatos, comer sólo la fruta que cae de los árboles y evitar la co- 
mercialización. 

Lo irónico es que en todos sus diversos campos —comercio, in- 
vestigación y navegación— el Web ya forma hasta tal punto parte de 
nuestras vidas que la familiaridad ha empañado nuestra percepción 
del propio Web. Para entender el Web en su sentido más amplio y 
profundo, para participar totalmente de la visión que mis colegas y yo 
compartimos, uno tiene que entender cómo nació el Web. 

La historia de cómo se creó el Web se ha contado en diversos li- 
bros y revistas. Muchos relatos que he leído se han distorsionado o 
son simplemente erróneos. El Web fue el resultado de muchas in- 
fluencias que llegaron a mi cabeza, pensamientos a medio formar, 
conversaciones dispares y experimentos aparentemente desconecta- 
dos. Yo lo fui reuniendo todo mientras continuaba con mi trabajo 
normal y mi vida personal. Di forma a la visión, escribí los primeros 
programas para el Web y encontré las siglas, actualmente presentes 
por todas partes, URL (entonces UDD, HTTP, HTML y, naturalmen- 
te, World Wide Web. Pero muchas otras personas, la mayoría desco- 
nocidas, contribuyeron con elementos esenciales, en su mayor parte 
del mismo modo casual. Un grupo de individuos que compartían un 
sueño común y que trabajaban juntos a distancia hicieron surgir un 
gran cambio. 

Mi relato de la verdadera historia mostrará cómo la evolución del 
Web y su esencia están inextricablemente unidas. Sólo entendiendo el 
Web a su nivel más profundo conseguirá la gente asimilar de verdad el 
potencial máximo que puede llegar a tener. 

Los periodistas siempre me han preguntado cuál fue la idea cru- 
cial, o qué hecho singular fue el que permitió al Web existir un día, 
después de que el día anterior no existiera. Todos se quedan frustra- 
dos cuando les digo que no hubo un momento de “¡Eureka!”. No fue 
como la legendaria manzana que cayó sobre la cabeza de Newton para 
demostrar el concepto de gravedad. Inventar el World Wide Web su- 
puso el darme cuenta de que había un poder en el hecho de ordenar 
ideas de un modo no constreñido, tipo Web. Y la conciencia de ello 
surgió precisamente a través de ese tipo de proceso. El Web surgió 


Preguntar en el interior acerca de cualquier cosa 3 


como la respuesta a un desafío abierto, a través de la amalgama de in- 
fluencias, ideas y logros procedentes de muchos lugares hasta que, 
gracias a los maravillosos oficios de la mente humana, un nuevo con- 
cepto cuajó. Fue un proceso de unión, no la resolución lineal de un 
problema bien definido detrás de otro. 

Soy hijo de matemáticos. Mi madre y mi dades fueron parte del 
equipo que programó el primer ordenador comercial con programa 
almacenado, el “Mark 1” de la Universidad de Manchester, que fue 
vendido por Ferranti Ltd. a principios de los cincuenta. Estaban 
emocionadísimos ante la idea de que, en principio, una persona 
pudiera programar un ordenador para hacer casi cualquier cosa. 
También sabían, sin embargo, que los ordenadores sirven muy bien 
para organizar y procesar lógicamente, pero no para hacer asocía- 
ciones al azar. Un ordenador guarda generalmente información en 
rígidas jerarquías y matrices, mientras que la mente humana tiene 
la habilidad especial de vincular fragmentos de datos al azar. Cuan- 
do huelo a café, fuerte y rancio, me veo a mí mismo de nuevo en 
un pequeño cuarto encima de un café que hacía esquina en Ox- 
ford. Mi cerebro forma un nexo y me transporta allí instantánea- 
mente. 

Un día, cuando volvía del instituto, encontré a mi padre traba- 
jando en un discurso para Basil de Ferranti. Estaba leyendo libros 
sobre el cerebro, buscando pistas acerca de cómo hacer que un ot- 
denador fuese intuitivo, capaz de efectuar conexiones, igual que 
hace el cerebro. Hablamos del tema; entonces mi padre siguió con 
su discurso y yo me fui a hacer los deberes. Pero me quedé con 
la idea de que los ordenadores podrían llegar a ser mucho más po- 
tentes si pudieran ser programados para relacionar información in- 
conexa. 

Este desafío siguió presente en mi mente mientras continué 
con mis estudios en el Queen's College de la Universidad de Ox- 
ford, donde me gradué en 1976 con un título de física. Continuó 
estando allí en un segundo plano cuando construí mi primer orde- 
nador con uno de los primeros microprocesadores, una vieja tele- 
visión y un soldador, así como durante los años que pasé como in- 
geniero de software en Plessey Telecommunications y en D. G. 
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Luego, en 1980, acepté un breve trabajo de consultoría de software 
en el CERN!, el famoso Laboratorio Europeo de Física de Partículas 
en Ginebra. Allí escribí Enquire, mi primer programa tipo Web. Lo 
escribí durante mi tiempo libre y para mi uso personal, y por la senci- 
lla razón de que quería que me ayudase a recordar las conexiones en- 
tre diversas personas, ordenadores y proyectos del laboratorio. Pero 
una idea mucho más amplia ya estaba enraizando firmemente en mi 
conciencia. 

Supongamos que toda la información almacenada en ordenadores de 
todas partes esté unida entre sí, pensé. Supongamos que pueda progra- 
mar mi ordenador para crear un espacio en el que cualquier cosa pueda 
relacionarse con cualquier otra. Todos los fragmentos de información 
. de cada ordenador que había en el CERN, y en el planeta, estarían a 
mi disposición y a la de cualquier otro. Habría un espacio único y glo- 
bal de información. 

Una vez que un fragmento de información en ese espacio estuviese 
etiquetado con una dirección, podría decir a mi ordenador que lo 
atrapase. Al poder tomar como referencia cualquier cosa con la misma 
facilidad, un ordenador podría representar asociaciones entre cosas 
que pudieran parecer no tener nada que ver entre sí pero que, en cier- 
to modo, compartirían de hecho una relación. Se formaría un Web de 
información. 

Los ordenadores pueden no encontrar la solución a nuestros 
problemas, pero serían capaces de hacer el trabajo pesado necesario, 
ayudando a nuestras mentes humanas encontrando intuitivamente 
caminos a través del laberinto. La emoción añadida consistía en que 
los ordenadores también podrían seguir y analizar las relaciones de 
conexión provisionales que definían gran parte de los funcionamien- 
tos de nuestra sociedad, desvelando en su totalidad nuevas formas de 
ver nuestro mundo. Un sistema capaz de hacer eso sería una cosa 
fantástica para directores, científicos sociales y, finalmente, para todo 
el mundo. 


1 El nombre CERN deriva del nombre del consejo internacional (Conseil Européen 
pour la Recherche Nucléaire), que puso en marcha inicialmente el laboratorio. El con- 
sejo ya no existe, y “Nuclear” ya no describe la física que se Jleva a cabo allí, así que 
mientras el nombre CERN se ha conservado, ya no se considera unas siglas. 


Preguntar en el interior acerca de cualquier cosa 5 


Desconocidas para mí en tan temprana etapa de reflexión, varias 
personas habían llegado a conclusiones similares, que nunca habían 
llegado a llevarse a cabo. Vannevar Bush, en otro tiempo decano de 
ingeniería en el MIT, se convirtió en director de la U. S. Office of 
Scientific Research and Development [Agencia de Investigación y De- 
sarrollo Científico] durante la Segunda Guerra Mundial y supervisó el 
desarrollo de la primera bomba atómica. En un artículo de 1945 en el 
Atlantic Montbly titulado “Cómo podríamos pensar”, escribió acerca 
de una máquina fotoelectromecánica llamada Memex, que podía, gra- 
cias a un proceso de codificación binaria, células fotoeléctricas y foto- 
grafía instantánea, realizar y seguir referencias cruzadas entre docu- 
mentos microfilmados. 

Ted Nelson, un visionario profesional, escribió en 1965 acerca de 
“Máquinas literarias”, ordenadores que permitirían a la gente escribir 
y publicar en un nuevo formato no lineal, que llamó hxpertexto. El hi- 
pertexto era un texto “no secuencial” en el que un lector no estaba 
obligado a leer en un orden determinado, sino que podía seguir nexos 
de unión y llegar al documento original a partir de una breve cita. Ted 
describía un proyecto futurista, Xanadu, en el que toda la informa- 
ción del mundo podía ser publicada en hipertexto. Por ejemplo, si es- 
tuviéramos leyendo este libro en hipertexto, podríamos seguir cual- 
quier vínculo desde mi referencia a Xanadu hasta llegar a otros 
detalles de ese proyecto. En la visión de Ted cada cita tendría un vín- 
culo que la devolvería a su fuente, permitiendo a los autores originales 
ser compensados con una pequeña cantidad cada vez que se leyese la 
cita. Tenía el sueño de una sociedad utópica en la que toda la informa- 
ción pudiese ser compartida entre gente que se comunicaba entre sí 
como entre iguales. Luchó durante años para encontrar financiación 
para ese proyecto, pero no encontró el éxito. 

Doug Engelbart, un investigador de la Universidad de Stanford, 
mostró un espacio de trabajo en cooperación llamado NLS (oN Line 
System) en los sesenta. La idea de Doug era que la gente usase el hi- 
pertexto como herramienta para trabajar en grupo. Á fin de ayudarse 
a sí mismo a dirigir el cursor a través de la pantalla y seleccionar los 
vínculos de hipertexto con facilidad, Doug inventó un bloque de ma- 
dera con sensores y una bola debajo, y lo llamó ratón. En un vídeo que 
actualmente es famoso y que no veo desde 1994, Doug mostraba 
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cómo usar correo electrónico y vínculos de hipertexto con gran agili- 
dad gracias a su ratón hecho en casa con la mano derecha, y un tecla- 
do de cinco teclas con la mano izquierda. La idea era que la persona 
pudiera actuar con la máquina de una manera muy cercana y natural. 
Por desgracia, igual que en el caso de Bush y Nelson, Doug estaba de- 
masiado adelantado a su tiempo. La revolución del ordenador perso- 
nal, que convertiría al “ratón” de Engelbart en algo tan familiar como 
un lápiz, no aparecería hasta quince años después. Con esa revolu- 
ción, la idea del hipertexto se filtraría en el diseño del software. 

Naturalmente, el siguiente gran desarrollo en la búsqueda de la 
conexión global sería Internet, una infraestructura de comunicaciones 
generales que une entre sí a todos los ordenadores, y que está gober- 
nado por el Web. Los avances de Donald Davis, Paul Barran y Vint 
Cerf, Bob Kahn y sus colegas ya tuvieron lugar en los setenta, pero por 
entonces no estaban más que empezando a penetrar. 

Yo llegué en el momento justo, interesado, cuando el hipertexto e 
Internet habían visto ya la luz. La tarea que me correspondía era hacer 
que casaran. 


2. ENREDOS, ENLACES Y REDES 


El centro de investigaciones de física de partículas conocido como 

CERN se encuentra en la frontera franco-suiza, cerca de la ciudad de 

Ginebra. Cobijado al pie de las paredes de piedra caliza de las monta- 

ñas del Jura, a diez minutos de las pistas de esquí, con el lago Leman a 

sus pies y el Mont Blanc en lo alto, ofrecía unas oportunidades de in- 
vestigación únicas, y la zona era un lugar muy agradable para vivir. 

Ingenieros y científicos llegaban al CERN procedentes de todo el 
mundo para investigar las propiedades más fundamentales de la mate- 
ria, Utilizando máquinas enormes, aceleraban minúsculas partículas 
nucleares a través de una serie de tubos que, aunque sólo tuviesen 
unos centímetros de ancho, recorrían varios kilómetros dentro de un 
gigantesco túnel circular subterráneo. Los investigadores aceleraban 
las partículas hasta energías extremadamente altas y luego las dejaban 
chocar. Durante un instante de brevedad inimaginable, se podían ha- 
- cer nuevas partículas que luego se perdían. El truco consistía en regis- 
trar los restos de alta energía procedentes del cataclismo mientras se 
precipitaban al interior de uno de los dos detectores que estaban den- 
tro del túnel, cada uno del tamaño de una casa, repleto de aparatos 
electrónicos. 

La investigación a esta escala era tan cara que necesitaba de la co- 
laboración de muchas naciones. Científicos visitantes llevaban a cabo 
sus experimentos en el CERN, y luego volvían a las instituciones de 
sus países a estudiar los datos conseguidos. Aunque había una instala- 
ción central, el CERN era en realidad una comunidad extensa de per- 
sonas que tenían una autoridad común bastante relativa. Los científi- 
cos traían consigo una amplia variedad de ordenadores, software y 
sistemas con ellos, y aunque procedían de diferentes culturas y habla- 
ban idiomas distintos, conseguían encontrar una forma de trabajar 
juntos gracias a su interés compartido por la física de partículas y su 
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deseo de ver que un enorme proyecto tuviera éxito. Era un ambiente 
tremendamente creativo. 

En 1980, el CERN se encontraba inmerso en el proceso de susti- 
tuir el sistema de control de dos de sus aceleradores de partículas. El 
trabajo se estaba atrasando y el CERN necesitaba ayuda. Yo estaba, 
por suerte, trabajando en otro lugar de Suiza cuando mi amigo y cole- 
ga Kevin Rogers llamó desde Inglaterra para sugerir que nos presentá- 
ramos. 

Cuando llegamos para ser entrevistados, a Kevin y a mí nos die- 
ron una vuelta por las instalaciones y pronto nos encontramos sobre 
una pasarela, contemplando desde arriba lo que parecía el suelo de 
una enorme y caótica fábrica. Esta enorme sala experimental estaba 
llena de experimentos en curso más pequeños, oscurecidos por las 
paredes de cemento que había entre ellos, construidas rápidamente 
para impedir el paso de las radiaciones. Avanzando por la pasarela, 
llegamos a la sala de control. Dentro había filas y más filas de hard- 
ware informático, sin más iluminación que el brillo de las muchas lu- 
ces de los indicadores y los relojes. Era el paraíso de un ingeniero 
electrónico, con columnas de osciloscopios, suministro de energía y 
equipo de secuenciación, la mayoría construidos especialmente para 
o por el CERN. 

En aquel momento un ordenador era aún una especie de santuario 
al que los científicos e ingenieros iban en peregrinación. La mayor 
parte de la gente del CERN no tenía terminales de ordenador en sus 
despachos; tenían que ir a una instalación central, como la sala de ter- 
minales que estaba junto a la sala de control, para programar realmen- 
te un sistema informático. Kevin y yo pronto nos uniríamos a un equi- 
po de personas que finalmente se haría con esa sala de control. 
Desgraciadamente, las filas de aparatos electrónicos brillantes serían 
poco a poco desmanteladas y sustituidas por un aburrido óvalo de 
consolas de ordenador, gobernadas por un software mucho más po- 
tente. 

El gran desafío para los programadores era intentar entender los 
sistemas, tanto humanos como informáticos, que hacían funcionar 
aquel fantástico campo de juegos. Gran parte de la información cru- 
cial existía sólo en la mente de las personas. Aprendimos muchísimo 
en conversaciones a la hora del café, en mesas estratégicamente colo- 
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cadas en la intersección de los dos pasillos. Me presentaron a gente 
entresacada del mar de caras desconocidas y tuve que recordar quié- 
nes eran y qué parte de equipo o de software habían diseñado. La es- 
tructura del CERN, semejante a una red, hacía la tarea aún más difícil. 
De las diez mil personas que estaban en la lista de teléfonos del 
CERN, sólo cinco mil más o. menos estaban en el CERN al mismo 
tiempo, y sólo tres mil más o menos eran auténtico personal asalaria- 
do. Muchos de los otros tenían un escritorio y venían de visita proce- 
dentes de sus instituciones sólo de vez en cuando. 

Para albergar a personas contratadas que llegaban de pronto para 
ayudar en algún proyecto u otro, la dirección había erigido cabinas 
portátiles en lo alto de una colina dentro del recinto. Hablábamos en 
grupos de nuestras ideas a la hora de la comida contemplando los vi- 
ñedos suizos o mientras caminábamos por el largo tramo de escalones 
de cemento que iba desde lo alto de la colina hasta la sala de experi- 
mentación y la sala terminal para hacer las programaciones. Yo llena- 
ba los momentos muertos cuando no estaba trabajando oficialmente 
en el Proton Synchotron Booster jugueteando con mi programa de 
juegos, el que llamaba Enquire. Cuando tuve terminada una primera 
versión, empecé a usarla para seguir la pista de quién había escrito 
cada programa, qué programa funcionaba en qué aparato y quién for- 
maba parte de qué proyecto. Las conversaciones informales en el 
CERN iban invariablemente acompañadas por diagramas de círculos 
y flechas dibujados en servilletas y sobres, porque era una manera na- 
tural de mostrar las relaciones entre la gente y los aparatos. Yo escribí 
un manual de cuatro páginas para el Enquire que hablaba de los círcu- 
los y las flechas, y lo útil que era utilizar su equivalente en un progra- 
ma de ordenador. 

En el Enquire, podía escribir una página de información acerca de 
una persona, un aparato o un programa. Cada página era un “nodo” 
en el programa, un poco como una tarjeta de un fichero. El único 
modo de crear un nuevo nodo era hacer un vínculo a partir de un anti- 
guo nodo. Los vínculos que salían o llegaban a un nodo aparecían 
como una lista numerada al pie de cada página, de forma bastante pa- 
recida a la lista de referencias al final de un informe académico. La 
única manera de encontrar información era empezando a mirar desde 
la primera página. 
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Me gustaba el Enquire, e hice buen uso de él porque almacenaba 
información sin utilizar estructuras como matrices o árboles, La men- 
te humana usa estas estructuras de organización continuamente, pero 
también puede romperlas y dar saltos intuitivos cruzando fronteras: 
las famosas asociaciones al azar. Cuando hube descubierto estas cone- 
xiones, el Enquire podía al menos almacenarlas.A medida que iba ex- 
pandiendo el Enquire, mantuve un foco de vigilancia para conservar 
las conexiones que estaba haciendo. El programa estaba estructurado 
de tal forma que yo sólo podía introducir un nuevo tema si lo vincula- 
ba a uno que ya existiera. Para formar cada vínculo tenía que describir 
cuál era la relación. Por ejemplo, si una página acerca de Joe estaba 
vinculada a una página acerca de un programa, tenía que decir sí Joe 
había hecho el programa, si lo había utilizado, o si qué, Una vez había 
dicho que Joe usaba el programa, Enquire también sabría, cuando 
mostraba información acerca del programa, que era usado por Joe. 
Los vínculos funcionaban así. 

El Enquire funcionaba en el ordenador de desarrollo de software 
del grupo. No lo hice funcionar a través de una red, y tampoco en In- 
ternet, que no se usaría en el CERN hasta muchos años después. El 
Enquire tenía dos tipos de vínculos: un vínculo “interno” de una pági- 
na (nodo) a otra en un archivo, y un vínculo “externo” que podía sal- 
tar de archivo a archivo. La distinción era fundamental. Un vínculo in- 
terno aparecería en ambos nodos. Un vínculo externo iba sólo en una 
dirección. Esto era importante porque, si mucha gente que estuviera 
haciendo ese vínculo a una página impusiera un vínculo de retorno, 
esa página tendría miles de vínculos que el dueño de la página podría 
no querer molestarse en almacenar. Es más, si un vínculo externo iba 
en ambas direcciones, entonces cambiar ambos archivos supondría al- 
macenar la misma información en dos sitios, lo que casi siempre trae 
problemas: los archivos acabarían inevitablemente perdiendo el paso. 

Finalmente, reuní una base de datos de personas y una base de da- 
tos de módulos de software, pero entonces acabó mi período como 
consultor. Cuando me fui del CERN, no me llevé el código de origen 
del Enquire. Lo había escrito en el lenguaje de programación Pascal, 
que era corriente, pero funcionaba en el sistema operativo Norsk Data 
SINTRAN-III, que era bastante confuso. Entregué el disquete de 
ocho pulgadas a un jefe de sistemas y le expliqué que era un programa 
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para seguir la pista de información. Dije que podía usarlo si quería. El 
programa fue entregado posteriormente a un estudiante que dijo que 
le había gustado la forma en que estaba escrito; como debería estarlo 
un programa Pascal. Las pocas personas que lo vieron pensaron que 
era una buena idea, pero nadie lo utilizó. Finalmente, el disquete se 
perdió, y con él, el Enquire original. 

Cuando me marché del CERN, me uní a un antiguo colega, John 
Poole. Dos años antes, Kevin y yo habíamos estado trabajando con 
John, tratando de mejorar las aburridas impresoras de matriz de pun- 
tos con el por entonces revolucionario microprocesadot, para que 
pudieran imprimir gráficos de fantasía. Los tres nos sentábamos en la 
habitación delantera de la casa de John, con el labrador dorado acu- 
rrucado debajo de uno de los escritorios, y tratábamos de perfeccio- 
nar el diseño. Lo conseguimos en unos meses, pero John no tenía di- 
nero para seguir pagándonos un sueldo, y no lo tendría hasta que 
vendiese el producto. Por eso empezamos a buscar un trabajo y acaba- 
mos en el CERN, 

Después de que yo estuviera seis meses en el CERN, John llamó. 
“¿Por qué no vuelves?” dijo. “He vendido el producto, tenemos un 
contrato. Ahora necesito apoyo de software.” John se había estableci- 
do como Image Computer Systems, y Kevin y yo volvimos a ayudar. 

Reescribimos todos los controles de motor para optimizar el movi- 
miento de la cabeza de la impresora para que fuera rápida. También 
podía imprimir en árabe, dibujar en tres dimensiones y conseguir el 
efecto de material de papelería preimpreso usando un papel menos 
caro. Escribimos nuestro propio lenguaje markup en el que se prepa- 
raban los documentos, y la impresora también podía manejar códigos 
de input de máquinas de escribir mucho más caras. También podía- 
mos cambiar no sólo las fuentes, sin casi cualquier aspecto del com- 
portamiento de la impresora. 

El negocio iba bien, pero la tecnología con la que estábamos tra- 
bajando era limitada en lo referente a lo que podíamos meter en una 
impresora. Yo sentí que necesitaba un cambio, que quería salir de In- 
glaterra, y recordé que el CERN tenía un programa de becas. En la 
primavera de 1983 decidí pedir una, que llegó finalmente en septiem- 
bre de 1984. Como regalo de despedida de Image, John me regaló un 
ordenador personal Compaq. Éste fue vendido como uno de los pri- 
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meros ordenadores “portátiles”, peró más parecía una máquina de co- 
ser, más “arrastrable” que portátil. Con mi nuevo PC y el entusiasmo 
que supone un cambio, escribí en mi tiempo libre otro programa de 
juegos, llamado Tangle [Enredo]. Quería seguir explorando las ideas 
acerca de conexiones que ya estaban evolucionando en mi cabeza. 


Desde un punto de vista extremo, el mundo puede considerarse como 
sólo un conjunto de conexiones, nada más. Consideramos un diccio- 
nario como un depósito de significados, pero define palabras sólo en 
términos de otras palabras. Me gustaba la idea de que un fragmento 
de información fuera realmente definido sólo por aquello con lo que 
está relacionado, y la forma en que está relacionado. Realmente hay 
muy poco más en el significado. La estructura lo es todo. Hay billones 
de neuronas en nuestros cerebros pero ¿qué son las neuronas? Sólo 
células. El cerebro no tiene conocimiento hasta que se hacen conexio- 
nes entre neuronas. Todo lo que sabemos, todo lo que somos, procede 
del modo en que están conectadas nuestras neuronas. 

Los ordenadores almacenan información como secuencias de ca- 
racteres, así que el significado para ellos está ciertamente en las cone- 
xiones entre caracteres. En el Tangle, si una determinada secuencia de 
caracteres se reproduce, crearía un nodo que representaría la secuen- 
cia. Cada vez que la misma secuencia volviera a aparecer, en lugar de 
repetirla, Tangle añadiría una referencia al nodo original. A medida 
que se fueran almacenando más frases como nodos, y más señaladores 
apuntasen a ellos, se formaría una serie de conexiones. 

La idea era la siguiente: lo que importa está en las conexiones. No 
está en las letras, está en el modo en que se juntan para formar pala- 
bras. No está en las palabras, está en el modo en que se juntan para 
formar frases. No está en las frases, está en el modo en que se juntan 
para formar un documento. Pensé en introducir en el ordenador una 
enciclopedia de ese modo, y luego hacer al Tangle una pregunta. La 
pregunta sería descompuesta en nodos, que sucesivamente se referi- 
rían a los mismos nodos que apareciesen en la enciclopedia. El enredo 
resultante contendría todas las respuestas relevantes. 

Probé el Tangle introduciendo la frase. “¿Cuánta madera tiraría 
una marmota?” [“How much wood would a woodchuck chuk?”] La 
máquina pensó un momento y codificó mi frase de una estructura de 
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datos muy compleja y enrevesada. Pero cuando le pedí que expusiese 
lo que había codificado, siguió todos los nodos e hizo aparecer de 
nuevo: “¿Cuánta madera tiraría una marmota?”. Me estaba empezan- 
do a sentir muy confiado, así que lo intenté con “How much wood 
would a woodchuck chuck if a woodchuck could chuck wood?”. Pen- 
sé un momento, lo codifiqué y cuando le pedí que lo decodificara, me 
contestó: “How much wood would a woodchuck chuck if a wood- 
chuck chuck wood chuck chuck chuck wood wood chuck chuck 
chuck...” y siguió así indefinidamente. El jaleo que se había armado 
era tan sumamente difícil de desenmarañar que nunca lo volví a tocar. 
Aquello fue el fin del Tangle, pero no el fin de mi deseo de representar 
el aspecto conectivo de la información. 

Siempre me he encontrado en el límite del hardware y del softwa- 
re, lugar que era importante y emocionante, especialmente a medida 
que el software fue dominando cada vez más las funciones del hard- 
ware. Cuando pedí mi beca para el CERN, especifiqué que quería un 
trabajo que me permitiese trabajar en ambas cosas, y sugerí tres luga- 
res en los que podría hacerlo. Acabé contratado para un trabajo en 
“adquisición y control de datos”, el grupo responsable de capturar y 
procesar los resultados de los experimentos. Peggie Rimmer, que me 
contrató, también acabaría enseñándome mucho acerca de métodos 
de escritura que iban a ser muy útiles con posterioridad. Aquella vez 
estaba en una posición en la que podía ver mucho más del CERN, 

“apreciar mejor su complejidad. Aunque perteneciente a una división 
central de ordenadores, mi grupo trabajaba con los grupos individua- 
les de experimentación, cada uno de los cuales estaba formado por 
una mezcla diversa de científicos de todo el mundo. 

En 1984 el CERN había crecido. Se estaba construyendo un nue- 
vo acelerador, el acelerador Large Electron Positron. Su túnel, de 
veintisiete kilómetros de circunferencia, recorría una distancia que iba 
desde un centenar de metros bajo el CERN hasta, en su punto más le- 
jano, trescientos metros por debajo de las laderas de las montañas del 
Jura, convirtiendo en muy pequeños a todos los demás aceleradores. 
La diversidad informática también había crecido. Se estaban usando 
una nueva generación de ordenadores, nuevos sistemas operativos y 
nuevos lenguajes de programación, así como una gran variedad de 
protocolos de redes para enlazar los diversos ordenadores que susten- 
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taban los grandes experimentos. Máquinas de IBM, Digital Equip- 
ment Corp. (DEC), Control Data; las teníamos todas, así como una se- 
lección de las novedades de PC o Macs en ordenadores personales y 
diversos procesadores de texto. 

La gente se traía sus.aparatos y sus costumbres con ellos, y los de- 
más tenían que hacer lo posible para adaptarse. Luego los equipos 
volvían a sus casas y, esparcidos como estaban por las diferentes zonas 
de horario y de idioma, seguían teniendo que colaborar juntos. En 
toda esta diversidad conectada, el CERN era un microcosmos del res- 
to del mundo, aunque iba a unos cuantos años por delante. 

Yo escribí un programa general “de llamada remota” (RPC) para 
facilitar la comunicación entre todos los ordenadores y redes. Con el 
RPC, un programador podía escribir un programa en una clase de or- 
denador pero pasaba la información a otros ordenadores, aunque fun- 
cionasen con diferentes programas operativos o lenguajes de ordena- 
dor. Las herramientas RPC trabajarían en cualquier red o cable que 
estuviese disponible en un caso determinado. 

Empecé a recrear el Enquire en el Compaq. Escribí el programa 
de modo que funcionase tanto en el pesado Compaq como en el mi- 
niordenador VAX fabricado por DEC que estaba usando en el 
CERN. No hice un trabajo tan bueno la segunda vez, sin embargo: 
sólo programé los vínculos internos y nunca llegué a escribir el código 
para los vínculos externos. Eso significaba que cada red estaba limita- 
da a las notas que pudieran encajar en un archivo: ningún vínculo po- 
dría conectar esos mundos cerrados. La naturaleza debilitadora de 
esta restricción fue una lección importante. 

Estaba claro que era necesario algo como el Enquire en el CERN. 
Además de seguir la pista de las relaciones entre todas las personas, 
los experimentos y las máquinas, yo quería tener acceso a diferentes 
clases de información, como los informes técnicos de un investigador, 
los manuales para diferentes módulos de software, los resúmenes de 
reuniones, las notas escritas a toda prisa, etc. Es más, me encontré a 
mí mismo respondiendo las mismas preguntas que muchas personas 
hacían sobre mí. Sería mucho más fácil si todo el mundo pudiera leer 
mi base de datos. 

Lo que estaba buscando entraba en la categoría general de síste- 
mas de documentación: software que permite que los documentos se 


Enredos, enlaces y redes 15 


puedan almacenar y más tarde se recuperen. Éste era un terreno de 
juego muy dudoso, sin embargo. Ya había visto a muchos llegando al 
CERN para colocar sistemas que “ayudaban” a la gente a organizar 
la información. Decían: “Para usar este sistema, lo único que tienen 
que hacer es dividir todos sus documentos en cuatro categorías” o 
“Sólo tienen que guardar sus datos como documento World Wonder- 
ful”, o lo que fuera. Los sistemas iban cayendo uno tras otro porque 
los vendedores intentaban obligar a los indignados investigadores a 
reorganizar su trabajo para que se ajustara a los sistemas. Yo habría 
creado un sistema con reglas comunes que fuese aceptable para 
todo. Eso quería decir que estuviera lo más cerca posible de no tener 
reglas en absoluto. 

Esta noción parecía imposible hasta que me di cuenta de que la di- 
versidad de los diferentes sistemas y redes de ordenadores podía ser 
una fuente muy rica; algo que debería estar representado, no un pro- 
blema que había que erradicar. El modelo que escogí para mi sistema 
minimalista fue el hipertexto. 

Mi idea era combinar de alguna manera los vínculos externos del 
Enquire con hipertexto y los esquemas de interconexión que había 
desarrollado para el RPC. Un programa de Enquire capaz de hacer 
vínculos externos de hipertexto era la diferencia entre la prisión y la li- 
bertad, la oscuridad y la luz. Se podían hacer nuevas redes para conec- 
tar diferentes ordenadores, y todos los nuevos sistemas serían capaces 
de escapar y referirse a otros. Además, cualquiera que estuviese 
echando una ojeada podría añadir instantáneamente un nuevo nodo 
conectado a un nuevo vínculo, 

El sistema tenía que tener otra propiedad fundamental: tenía que 
estar completamente descentralizado. Ése sería el único modo en que 
una nueva persona pudiera empezar a usarlo en cualquier parte sin te- 
ner que pedir acceso a otro. Y sería el único modo para que el sistema 
pudiera adaptarse de modo que, aunque lo usara cada vez más gente, 
no se atascase. Esto era auténtica ingeniería al estilo de Internet, pero 
la mayoría de los sistemas seguían dependiendo de algún nodo central 
al que todo debía conectarse, y cuya capacidad limitaba el crecimiento 
del sistema como conjunto. Yo quería que el hecho de añadir un nue- 
vo vínculo fuese trivial; si lo era, entonces se podía extender regular- 
mente un Web de vínculos por todo el globo. 
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Mientras no introdujera una base central de datos de vínculos, 
todo se adaptaría muy bien. No habría nodos especiales ni vínculos 
especiales. Cualquier nodo podría enlazar con cualquier otro nodo. 
Esto daría al sistema la flexibilidad necesaria, y sería la clave de un sis- 
tema universal. El espacio abstracto de documentos que suponía po- 
dría contener cualquier tema de información accesible en redes; y 
toda la estructura y enlaces que hubiera entre ellos. 

El hipertexto funcionaría al máximo rendimiento si pudiera acce- 
der a cualquier cosa concebible. Cada nodo, documento —o como se 
llamara—, sería fundamentalmente equivalente de alguna manera. 
Cada uno tendría una dirección de referencia. Todos existirían juntos 
en el mismo espacio: el espacio de la información. 


A finales de 1988 yo estaba conspirando para conseguir un sistema de 
hipertexto que funcionase. Hablé con mi jefe, Mike Sendall. Él dijo 
que le parecía una idea razonable, pero que debería escribir una pro- 
puesta. ¿Una propuesta? No tenía idea de lo que había que poner en 
una “propuesta” en el CERN, Pensé, sin embargo, que nunca conse- 
guiría el visto bueno para desarrollar un sistema de documentación de 
hipertexto a menos que éste fuese aprobado como proyecto formal. 
Cavilé a fondo acerca de cómo meter lo emocionante de la idea en un 
texto que convenciese a la gente del CERN. 

Aunque el Enquire proporcionaba un modo de vincular docu- 
mentos y bases de datos, y el hipertexto proporcionaba un forma- 
to común en el que mostrarlos, seguía habiendo el problema de 
conseguir que diferentes ordenadores con diferentes sistemas pu- 
diesen comunicarse unos con otros. Ben Segal, uno de mis mento- 
res en el proyecto RPC, había trabajado en Estados Unidos y ha- 
bía visto Internet. Desde entonces se había convertido en un 
evangelizador solitario para que éste se usase en el CERN. Anda- 
ba por allí señalando cómo Unix e Internet estaban conectando 
laboratorios y universidades de toda América, pero encontraba 
mucha resistencia. Internet era casi invisible en Europa porque la 
gente estaba buscando una serie distinta de protocolos de redes 
que estaban siendo diseñados y promocionados por la Internatio- 
nal Standards Organization (ISO). Ya fuese por el sentimiento de 
“no se ha inventado aquí”, o por honradas razones técnicas, los 


Enredos, enlaces y redes ] 17 


europeos estaban intentando diseñar su propia red internacional 
en comité. 

Pero a mí me intrigaba Internet. Internet es una infraestructura 
de comunicaciones muy general que enlaza ordenadores. Antes de In- 
ternet, los ordenadores se conectaban usando delicados cables de 
uno a otro. Un programa de software de un ordenador se comunica- 
ba por el cable con el programa de software de otro ordenador y 
mandaba información, como un archivo o un programa, por ejemplo. 
Esto se hizo originalmente para que los primeros carísimos ordena- 
dores de un laboratorio o empresa pudieran ser utilizados desde dife- 
rentes sitios. Pero estaba claro que un ordenador no podía conectarse 
a muchos más, porque necesitaría decenas o centenares de cables de 
uno a otro. 

" La solución era comunicarse indirectamente a través de una red. 
Internet es una red de redes. Su esencia, sin embargo, es una serie de 
protocolos estándar, convenciones gracias a las cuales los ordenadores 
se mandan datos unos a otros. Los datos son transmitidos por diferen- 
tes mensajeros, como líneas telefónicas, cables de televisión y canales 
satélite. Los datos pueden ser textos, correo electrónico, un sonido, 
una imagen, un programa de software, lo que sea. Cuando un ordena- 
dor está listo para enviar sus datos, usa un software especial para des- 
componer los datos en paquetes que conforman los dos protocolos de 
Internet que gobiernan el modo en que los paquetes serán enviados: 
IP (Internet Protocol) y TCP (Transmission Control Protocol). El 
software etiqueta cada paquete con un número único. Envía los pa- 
quetes por el teléfono o el cable y el ordenador que lo recibe usa su 
propio software de Internet para descifrarlos según las etiquetas. 

Internet estaba en marcha en los setenta, pero transferir informa- 
ción era un jaleo para una persona no experta en ordenadores. Uno 
ponía en marcha un programa para conectarse con otro ordenador y 
entonces en la conversación (en un idioma diferente) con el otro orde- 
nador, ponía en marcha un programa diferente para acceder a la infor- 
mación. Incluso cuando los datos se habían transferido de vuelta al 
propio ordenador, decodificarlos podía resultar imposible. 

Entonces se inventó el correo electrónico. El e-mail permitía en- 
viar mensajes de una persona a otra, pero no formaba un espacio en el 
que la información pudiera existir permanentemente y se pudiera ac- 
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ceder a ella. Los mensajes eran transitorios (cuando llegó el World. 
Wide Web, cabalgando sobre Internet, daría a la información un lugar 
en el que permanecer). 

La tardanza del CERN en adoptar Internet fue sorprendente, por- 
que el laboratorio había sido pionero en las redes y las telecomuni- 
caciones. Había desarrollado la CERN-net, sá propia red hecha en 
casa, debido a la falta de redes comerciales: Tenía sus propios sistemas 
de e-mails. Y estaba a la cabeza de las conexiones entre diferentes pro- 
pietarios de sistemas de correo y archivos. 

Yo estaba interesado en Internet porque quizás podría proporcio- 
nar un puente entre distintos sistemas operativos y redes informáticas. 
El CERN era un crisol tecnológico. Muchos físicos estaban acostum- 
brados al sistema operativo VAX/VMS de Digital y a los protocolos 
de comunicación DECnet. Otros preferían el sistema rival en creci- 
miento Unix, que usaba los protocolos de Internet. Cada vez que se 
ponía en marcha un nuevo experimento, había luchas acerca de si usar 
VAX/VMS y DECnet, o Unix y TCP/IP. Yo estaba empezando a pre- 
ferir TCP/TP, porque TCP comenzaba a estar disponible para VMS 
también. Inicialmente no provenía de Digital, sino de la Universidad 
de Wollongong, en Australia. 

Usar TCP/TP significaría que el mundo de Unix, que ya usaba 
TCP/1P, estaría satisfecho, y los que estaban en el mundo de VAX 
también podrían entrar en el mundo de Unix. Finalmente, hubo una 
forma de que ambos competidores se comunicaran entre sí, pidiendo 
un elemento de software de TCP/IP a Wollongong. Me convenció 
tanto la importancia de TCP/TP que añadí un código al sistema RPC 
para que pudiera comunicarse usando TICP/TP, y creé un sistema de 
envíos para él que identificaba cada servicio remoto en el sistema 
RPC. Entonces fue cuando Internet entró en mi vida. 

Para la propuesta, también tuve que pensar lo que se necesitaba 
para meter el Enquire en un sistema global. Tendría que vender el 
proyecto como un sistema de documentación —una necesidad que se 
percibía en el CERN— y no como un sistema de hipertexto, que sona- 
ba demasiado importante. Pero si ese sistema iba a funcionar como un 
modo de acceder a información a través de un Web, entraría en com- 
petición con otros sistemas de documentación del CERN. Como ha- 
bía visto cómo fracasaban sistemas anteriores, supe que la clave sería 
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subrayar el hecho de que cada persona pudiera conservar su propio 
estilo de organización y software de su ordenador. 

El sistema necesitaba una forma simple de que la gente pudiera re- 
presentar vínculos en sus documentos, y navegar entre los vínculos. 
Había un modelo en programas de “ayuda” online. Si había una or- 
den o herramienta en la pantalla que el usuario no entendía, cliqueaba 
en ella y aparecía más información. Este sistema se llamó hot buttons 
[botones calientes] un derivado del hipertexto de Ted Nelson que ha- 
bía sido usado posteriormente por el “Hypercard” de Apple Compu- 
ter y más tarde, de un modo u otro, por muchos sistemas de señalar y 
cliquear. Decidí que en mi sistema, si alguien quería poner un vínculo 
de hipertexto en un fragmento de texto, las palabras que indicasen el 
vínculo aparecerían destacadas de alguna manera en la pantalla. Si un 
espectador cliqueaba en una palabra destacada, el sistema le llevaría a 
ese vínculo. 


Las piezas estaban empezando a encajar. TCP/1P sería el protocolo de 
red escogido. Para fines de “marketing”, propondría que el sistema 
funcionara con DECnet, con el beneficio añadido de que se podría 
comunicar también por medio de Internet. Quedaba un hueco: para 
que la gente se comunicara y compartiera documentos, tenía que te- 
ner un esquema sencillo, pero común, de envío, para que supieran 
cómo enviar sus archivos y otros pudieran saber cómo pedir archivos. 
Adapté el sencillo esquema de envío de RPC. 

Al presentar mis argumentos a un grupo experimental, señalaría 
que ellos tendrían normalmente diferentes clases de información do-. 
cumentada —un programa de “ayuda”, un listín de teléfonos, un sis- 
tema de información de conferencias, un sistema de biblioteca remo- 
ta— y buscarían un modo de crear un sistema maestro consistente. 
Tendrían tres opciones: (1) diseñar otro esquema de documentación 
más que sería supuestamente mejor que los anteriores; (2) usar uno 
de los esquemas existentes y funcionar con sus limitaciones; o (3) 
darse cuenta de que todos esos sistemas remotos tenían algo en co- 
mún. Les diría: “Podemos crear una base común para comunicación 
a la vez que permitimos a cada sistema mantener su individualidad. 
De eso trata esta propuesta, y el hipertexto global es lo que les per- 
mitirá hacerlo. Lo único que tienen que hacer es fabricar una direc- 
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ción para documento o pantalla que haya en sus sistemas, y el resto 
es fácil”. 

En marzo de 1989 me decidí a escribir la propuesta. Quería expli- 
car que la generalidad era la esencia de un Web de información. Por 
otra parte, tenía la sensación de que tenía que hacer ver que el sistema 
sería algo que sólo pudiera utilizarse en el CERN, Estaba emocionado 
ante la idea de escapar de la camisa de fuerza de los sistemas de docu- 
mentación jerárquica, pero no quería que la gente responsable de 
cualquier sistema jerárquico me tirase piedras. Tenía que mostrar 
cómo este sistema podía integrar cosas muy distintas, así que propor- 
cioné el ejemplo del mensaje de un grupo de noticias de Internet, y 
una página de mi viejo programa Enquire. 

Era lo bastante temerario como para pretender tener un Web de 
datos que pudiera procesar mi máquina. Dije: 


Una posibilidad intrigante, dada una gran base de datos de hipertexto 
con vínculos mecanografiados, es que permite cierto grado de análisis 
automático [...] Imaginemos que fabricamos un gran modelo tridimen- 
sional, con gente representada por pequeñas esferas, y cordeles entre 
las personas que tienen algo en común en el trabajo. 

Ahora imaginemos que cogemos la estructura y la sacudimos, hasta 
que el enredo tenga cierto sentido: quizá veamos grupos muy apreta- 
dos en algunos lugares, y en otros lugares zonas vacías de comunica- 
ción pobladas sólo por unas pocas personas. Quizá un sistema de in- 
formación vinculada podría permitirnos ver la estructura real de la 
organización en la que trabajamos. 


Qué lejos estaba de pensar que se harían tesis de doctorados de filoso- 
fía sobre ese tema. 

En lo que se refería a las decisiones acerca de qué puntos técnicos 
incluir o excluir en la propuesta, y qué ventajas sociales subrayar del 
sistema, no me preocupé mucho de los detalles de gestión del pro- 
ducto: 


Imagino que dos personas durante seis a doce meses serían suficientes 
para esta fase del proyecto. Una segunda fase, supondría casi con segu- 
ridad llevar a cabo programaciones para instalar un auténtico sistema 
en el CERN en muchas máquinas. Una parte importante de esto, de la 
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que se habla más abajo, es la integración de un sistema de hipertexto 
con datos existentes, para proporcionar un sistema universal y para 
conseguir una utilidad crítica en una etapa temprana. 


A finales de marzo de 1989 había entregado la propuesta a Mike 
Sendall, a su jefe David Williams y a unos cuantos más. Se lo di a gente 
de un comité central que supervisaba la coordinación de los ordena- 
dores del CERN. Pero no hubo un foro en el que pudiera encontrar 
una respuesta. No pasó nada. 

Mientras esperaba alguna clase de respuesta, puse a prueba la idea 
en conversaciones, y las reacciones fueron diversas. La gente del 
CERN se movía entre varias lealtades superpuestas, quizá al CERN, al 
hecho de experimentar, a una idea, a un mado de hacer las cosas, a su 
instituto original... por no hablar del grupo de los usuarios de Macin- 
tosh o los de los PC/IBM. Otra razón para la falta de respuesta fue 
que el CERN era un laboratorio de física. Había comités que decidían 
sobre los experimentos apropiados porque era en lo que se trabajaba, 
pero la tecnología de la información era mucho más un medio para un 
fin, con menos estructura que la dirigiera. La situación era peor para 
las ideas muy generales como el hipertexto global. Incluso el proyecto 
del RPC, que también era un ejercicio general, tuvo poco apoyo for- 
mal desde el interior del CERN, pero tuvo bastante apoyo entre dife- 
rentes grupos que conseguí hacer funcionar con continuidad. 

Mientras tanto, me enfrasqué más en Internet y estudié sobre el 
hipertexto. Entonces fue cuando me convencí más que nunca de que 
estaba en el camino correcto. Á principios de 1990 seguía sin tener 
reacciones a mi propuesta. Decidí intentar despertar el interés de 
nuevo enviándola otra vez. La reformateé y le puse una nueva fecha: 
mayo de 1990. Se lo di de nuevo a David Williams, y de nuevo fue 
archivado. 

Durante esa época estaba en conversaciones con Mike Sendall 
acerca de comprar un nuevo tipo de ordenador personal llamado el 
NeXT. Steve Jobs acababa de poner en marcha NeXT Inc.; era el fun- 
dador de Apple Computer y aportó a los ordenadores personales el 
primer sistema intuitivo de señalar y cliquear (con el ratón) y una orga- 
nización de la información en carpetas. Ben Segal, nuestro evangelista 
de Unix e Internet, había mencionado que la máquina NeXT tenía 
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muchas características intrigantes que podrían ayudarnos. Pedí a 
Mike que me dejara comprar una (haciéndome acompañar por Ben 
como ayuda moral), y él accedió. También dijo: “Cuando tengáis la 
máquina, ¿por qué no tratáis de programar el asunto ése del hipertex- 
to en ella?”. Me pareció verle guiñar un ojo. 

Al comprar el NeXT, pudimos justificar qué yo trabajara en mi 
proyecto tanto tiempo abandonado del hipertexto como un experi- 
mento para usar el sistema operativo y entorno de desarrollo del 
NeXT. Inmediatamente empecé a pensar en un nombre para mi pro- 
yecto naciente. Buscaba palabras que sugirieran su nuevo tipo de es- 
tructura. Malla [Mesh], o Malla de Información, era una de las ideas 
(utilizada en el diagrama de la propuesta), pero sonaba quizá demasia- 
do parecido a mess [jaleo, desastre]. Pensé en Mina de Información 
[Mine of Information], o MOL, pero »zo1 en francés, significa “yo”, y 
era demasiado egocéntrico. Una alternativa era The Information 
Mine, pero la siglas, TIM, ¡eran más egocéntricas todavía! Además, la 
idea de mina no era demasiado exacta, porque no encerraba la idea de 
algo global, o de hipertexto, y representaba sólo sacar información, no 
meterla. 

También estaba buscando unas siglas características. Decidí que 
empezaría todos los programas implicados en este sistema con las le- 
tras “HT” de hipertexto. Luego apareció otro nombre como una for- 
ma sencilla de representar el hipertexto global. Este nombre se usaba 
en matemáticas como forma de indicar una colección de nodos y vín- 
culos en los que cualquier nodo puede ser vinculado a cualquier otro. 
El nombre reflejaba la naturaleza dispersada de las personas y los or- 
denadores que el sistema podía vincular. Ofrecía la promesa de un sis- 
tema potencialmente global. 

Amigos en el CERN me hicieron pasar malos ratos, diciendo que 
el asunto nunca despegaría, sobre todo porque tenía unas siglas que, 
cuando se pronunciaban, tenían nueve sílabas. De todos modos, deci- 
dí seguir adelante. Llamaría a mi sistema el “World Wide Web”. 


3.  info.cern.ch 


Fue muy difícil convencer a la gente del CERN de que el hipertexto 
global era una cosa muy emocionante, pero hubo una persona con- 
vencida desde el primer momento: Robert Cailliau. 

Aunque ahora sea el departamento de Electronics and Compu- 
ting for Physics, casualmente Robert había estado en 1980 en el 
mismo departamento de Proton Synchotron que yo, y había escrito 
de hecho el programa para formatear textos que tuve que usar para 
imprimir el manual del Enquire. Robert era un belga de lengua fla- 
menca que había tenido durante toda la vida la frustración de que 
la gente insistiera en dirigirse a él en francés. Tras graduarse en in- 
geniería en la Universidad de Gante, hizo un master en la Universi- 
dad de Michigan, una experiencia que le dejó un acento inglés im- 
posible de identificar. Ciertamente, se convirtió en juego de salón 
para los recién llegados al CERN tratar de adivinar de dónde pro- 
cedía. 

Robert es una persona atildada que organiza sus cortes de pelo se- 
gún los solsticios y los equinoccios, y es muy puntilloso en todo. Es la 

clase de ingeniero al que puede volver loco la incompatibilidad de los 
- enchufes. No es de extrañar, pues, que se sintiera atraído por una so- 
lución para la incompatibilidad de los ordenadores, especialmente si 
procedía de un sencillo interface. En el matrimonio del hipertexto e 
Internet, Robert fue el padrino. 

El auténtico don de Robert era el entusiasmo, traducido en un ge- 
nio especial para difundir el evangelio. Mientras yo me disponía a em- 
pezar a escribir el código del Web, Robert, cuyo despacho estaba a 
unos minutos andando, ponía toda su energía en el empeño de que el 
proyecto WWW se realizase en el CERN. Escribió una nueva pro- 
puesta en términos que a él le pareció que tendrían más efecto. Lleva- 
ba en el CERN desde 1973 y ejerció presiones entre el amplio grupo 
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de amistades que tenía en la organización. Buscó ayudantes estudian- 
tes, dinero, aparatos y espacio de oficinas. 

Cuando Mike Sendall aprobó mi compra del aparato NeXT, yo ya 
me había dirigido a la industria del hipertexto en busca de productos 
en los que pudiéramos llevar a cuestas el Web. En el CERN había una 
filosofía de “Compra, no construyas” en lo que:se refería a adquirir 
nueva tecnología. Había varios editores comerciales de hipertexto, y 
pensé que podíamos limitarnos a añadir algún código de Internet para 
que los documentos de hipertexto pudieran ser enviados por Internet. 
Creí que las compañías implicadas en el por entonces marginal campo 
de los productos de hipertexto se interesarían inmediatamente por las 
posibilidades del Web. Por desgracia, su reacción fue la contraria. 
“No”, dijeron. “Demasiado complicado.” 

Inasequibles al desaliento, en septiembre de 1990 Robert y yo asis- 
timos a la Conferencia Europea sobre Tecnología de Hipertextos 
(ECHT) en Versalles para lanzar la idea. La exposición de la conferen- 
cia era pequeña, pero había muchos productos en exhibición, como 
por ejemplo un manual multimedia para enseñar a reparar un coche. 

Hablé con lan Ritchie y con los chicos de Owl Ltd., que tenían 
un producto llamado Guide. En la obra original de Peter Brown en 
la Universidad de Southampton, cuando un usuario cliqueaba en un 
vínculo de hipertexto, el nuevo documento se insertaba exactamente 
en ese lugar. La versión que ahora comercializaba Owl se parecía de 
manera asombrosa a lo que yo había imaginado para una persona 
que buscase en el Web: el programa que abriría y mostraría docu- 
mentos, y preferiblemente permitiría a la gente que también los edi- 
tase. Lo único que faltaba era Internet. ¡Ya han hecho lo difícil! pen- 
sé, y traté de convencerles de que añadiesen una conexión a Internet. 
Estuvieron bastante simpáticos, pero tampoco ellos acababan de 
convencerse. 

La misma respuesta me dieron otras personas en la conferencia. 
Parecía que explicar la visión del Web a personas estaba siendo exce- 
sivamente difícil sin un navegador de Web a mano. La gente tendría 
que poder acceder al Web en su totalidad, lo que significaba imaginar 
un mundo entero poblado de sitios web y navegadores. Tenían que in- 
tuir el espacio de información abstracta que el Web podría convertir 
en realidad. Era pedir demasiado. 
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La comunidad del hipertexto también podía estar ligeramente 
desmoralizada. Su pequeña conferencia no estaba creciendo nada, y 
nadie estaba seguro de a dónde se dirigía el asunto. La falta de éxitos 
comerciales había dejado quizá un cierto cinismo con respecto a las 
nuevas ideas que podrían cambiar el mundo. 

- Otra posibilidad que contemplé se llamaba Dynatext, y procedía 
de Electronic Book Technology, una compañía de Rhode Island pues- 
ta en marcha por Andy Van Dam, el investigador de la Universidad 
Brown que había acuñado el término l¿bro electrónico. Me pareció que 
el software de la compañía podía convertirse en un navegador/editor 
del Web de una manera bastante fácil. Sin embargo, como muchos 
productos de hipertexto de la época, estaba construido alrededor de 
la idea de que un libro ha de ser “compilado” (como un programa de 
ordenador) para convertirlo, de la forma en que está escrito, en una 
forma en que pueda mostrarse de manera eficaz. Acostumbrados a ese 
proceso engorroso de muchos pasos, la gente de EBT no podía tomat- 
me en serio cuando les sugerí que el lenguaje codificado original podía 
enviarse por el Web y ser mostrado instantáneamente en la pantalla. 

También insistieron en una base central de datos con vínculos 
para asegurarse de que no hubiera vínculos rotos. Su visión se limita- 
ba a enviar textos fijos y consistentes, como por ejemplo, libros ente- 
ros. Yo estaba buscando un mundo viviente de hipertextos en el que 
todas las páginas estuvieran cambiando constantemente. Era un salto 
filosófico enorme. Dejar a un lado esta necesidad de consistencia era 
un paso crucial de diseño que permitiría al Web redimensionar. Pero, 
sencillamente, las cosas no se hacían así. 


A pesar del credo del “Compra, no construyas”, llegué a la conclusión 
de que iba a tener que crear el Web por mi cuenta En octubre de 
1990 empecé a escribir un código para el Web en mi nuevo ordena- 
dor El interface del NeXT era hermoso, suave y consistente. Tenía 
una gran flexibilidad y otros rasgos que no se verían en los PC hasta 
más tarde, como un e-mail de voz, y un sintetizador integrado. Tam- 
bién tenía software para crear un programa de hipertexto. Su fracaso 
en hacerse con la industria, a pesar de todas esas ventajas, se convirtió 
para mí en una advertencia. NeXT requería que los usuarios acepta- 
ran todas esas innovaciones enseguida: demasiado. 
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Mi primer objetivo era escribir el cliente del Web; el programa que 
permitiría la creación, navegación y edición de páginas de hipertexto. 
Tendría básicamente el aspecto de un procesador de textos, y las he- 
rramientas del sistema NeXT, llamadas NeXTStep, eran ideales para 
esa tarea. Podía crear una aplicación, menús y ventanas fácilmente, 
sólo con arrastrarlas y ponerlas en su sitio con el ratón. El meollo del 
asunto era crear la actual ventana de hipertexto. Aquí tuve que codifi- 
car algo, pero tenía un punto de partida, y pronto dispuse de un pro- 
cesador de textos completo funcionando, con múltiples fuentes, pá- 
rrafos, formateo de caracteres, ¡y hasta un corrector de ortografía! La 
gratificación fue inmediata. Ya podía ver el aspecto que tendría el sis- 
tema. 

Aún tenía que encontrar una manera de convertir texto en hiper- 
texto. Eso requería poder distinguir texto que fuese un vínculo, de 
texto que no lo fuese. Rebusqué en los archivos que definían los fun- 
cionamientos internos del editor de texto, y felizmente encontré un 
fragmento de memoria de treinta y dos bits libres que los que desarro- 
llaron el NeXT dejaron amablemente abierto para su uso ulterior por 
parte de fisgones como yo. Podía usar el espacio libre como puntero 
desde cada sección de texto hasta la dirección para cualquier vínculo 
de hipertexto. Con esto, el hipertexto resultaba fácil. Entonces pude 
escribir rápidamente el código para el Protocolo de Transferencia de 
Hipertexto [Hypertext Transfer Protocol] (HTTP), el lenguaje que 
los ordenadores usarían para comunicarse por Internet, y el Identifi- 
cador de Recursos Universal [Universal Resource Identifier] (URD, el 
esquema para direcciones de documentos. 

Hacia mediados de noviembre tuve un programa cliente —un na- 
vegador/editor de señalar y cliquear—, que llamé World Wide Web. 
En diciembre estaba funcionando con el Lenguaje Markup de Hiper- 
texto [Hypertext Markup Language] (HTML) que había escrito, que 
describe cómo formatear páginas que contengan vínculos de hiper- 
texto. El navegador decodificaría los URIs y me permitiría leer, escri- 
bir o editar páginas web en HTML. Podría navegar por el Web usan- 
do HTTP, aunque podría guardar documentos sólo en el sistema de 
ordenador local, no en Internet. 

También escribí el primer servidor del Web; el software que con- 
tiene páginas web en una parte de un ordenador y permite a otros ac- 
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ceder a ellas Como el primer cliente, el servidor funcionaba de ver- 
dad en mi aparato NeXT. Aunque el servidor era formalmente cono- 
cido como nxoc01.cern.ch (NeXT, Online Controls, 1), registré un 
alias para él —“info.cern.ch”— con los chicos del sistema de ordena- 
dores del CERN. De ese modo, el servidor no estaría atado por su di- 
rección a mi aparato NeXT, si trasladaba su contenido a otro aparato, 
todos los vínculos de hipertexto que apuntasen a él podrían encon- 
trarlo. Empecé la primera página web de hipertexto global en el servi- 
dor info.cern.ch, con mis propias notas, especificaciones de HTTP, 
URI y HTML, y toda la información relacionada con el proyecto. 

En ese momento Robert compró su propio aparato NeXT y nos 
divertimos poniendo en práctica nuestras ideas: comunicación entre 
hipertexto compartido. 

Por fin pude demostrar qué aspecto tendría el Web. Pero funcio- 
naba sólo en una plataforma, bastante poco corriente: el NeXT. El 
servidor HTTP también era muy tosco. Quedaba mucho camino por 
recorrer, y necesitábamos ayuda. Ben Segal, a quien se le daba muy 
bien acoplar al personal entre bastidores, localizó a una joven interna 
llamada Nicola Pellow. Nicola era una estudiante de matemáticas in- 
glesa que trabajaba para un colega en un edificio vecino, pero no tenía 
mucho que hacer. 

Un gran incentivo para meter un documento en el Web era que 
cualquier persona en el mundo pudiera encontrarlo. Pero ¿quién iba a 
molestarse en instalar un cliente si todavía no había suficiente infor- 
mación interesante en el Web? Salir de esa situación del huevo y la ga- 
llina era la tarea que teníamos por delante. Queríamos ser capaces de 
decir que sí algo estaba en el Web, entonces cualquiera podría tener 
acceso a ello; ¡no sólo alguien que tuviera un NeXT! 

Cuando yo daba charlas, mostraba un diagrama con aparatos de 
todas clases conectados a Internet, desde ordenadores centrales con 
sencillos terminales que manejasen sobre todo caracteres, hasta PC, 
Macs y otros. Para que eso fuera posible, pedí a Nicola que diese al 
Web el mejor navegador que pudiera, pero que diese por supuesto lo 
menos posible, para que ese interface pudiera trabajar con cualquier 
clase de ordenador. El mínimo común denominador que podíamos 
dar por supuesto entre todos los tipos diferentes de ordenadores era 
que tenían algún tipo de teclado y que todos podían realizar caracte- 
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res ASCII (texto corriente). El navegador tendría que ser tan básico 
que pudiera funcionar hasta en un teletipo para papel. Por tanto, lo 
llamamos navegador modo-línea, porque los teletipos y los primeros 
terminales de ordenador operaban mostrando una línea de téxto de 
cada vez. 

Mientras tanto, di un rápido paso que demostraría el concepto de 
Web como un espacio universal, que lo comprendiera todo. Programé 
el navegador para que pudiera seguir vínculos no sólo hasta archivos 
en los servidores HTTP, sino también en artículos de noticias y grupos 
de noticias de Internet. Estos no se transmitían en el protocolo HTTP 
del Web, sino en un protocolo de Internet llamado FTP (fzle transfer 
protocol) [protocolo de transferencia de archivos]. Con este movi- 
miento, los grupos de noticias y artículos de Internet se encontraron 
de pronto disponibles como páginas de hipertexto. De un golpe, una 
gran cantidad de la información que ya estaba en Internet estaba dis- 
ponible en el Web. 

El navegador/editor World Wide Web estaba funcionando en mi 
aparato y el de Robert, comunicándose por Internet con el servidor 
info.cern.ch el día de Navidad de 1990. 

Por muy significativo que fuese este hecho, yo no estaba muy con- 
centrado en él, porque mi esposa y yo esperábamos a nuestro primer 
hijo, precisamente para la Nochebuena. El destino quiso que se retra- 
sase unos días. Fuimos al hospital durante una tormenta el día de No- 
chevieja y nuestra hija nació al día siguiente. Por asombroso que pu- 
diera ser el ver desarrollarse al Web, nunca podría compararlo con ver 
el desarrollo de nuestra hija. 


A medida que iba pasando el nuevo año, Robert y yo animamos a la 
gente del departamento de Computing y Networking a que probaran 
nuestro sistema. Ellos no veían cómo podía serles útil. Esto creó una 
gran tensión entre nosotros acerca de cómo desplegar nuestros limita- 
dos recursos. ¿Deberíamos difundir el Web? ¿Deberíamos desarro- 
llarlo más en el NeXT? ¿Deberíamos reprogramarlo para el Mac, el 
PC o el Unix, porque aunque el NeXT fuera un aparato eficiente, no 
lo tenían muchas personas más? Después de todo, ¿de que servía un 
Web “mundial” si sólo había unos pocos usuarios? ¿Deberíamos 
adaptar el Web para que sirviera a la comunidad de físicos de alta 
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energía, para que tuviesen una herramienta que fuese suya y la apoya- 
sen, ya que el CERN estaba pagando nuestros sueldos? ¿O debería- 
mos generalizar el Web y dirigirnos realmente a la comunidad global, 
a riesgo de ser personalmente desautorizados por el CERN? 

Cambiar el NeXT por un ordenador cualquiera habría sido como 
cambiar un coche deportivo por una camioneta. Más importante aún, 
el Web ya estaba escrita para él. Si desarrollábamos el Web para el 
mucho más extendido PC, la aceptación podría ser más rápida, pero 
la cuestión era hacer probar a la gente lo que ya teníamos. Si detenía- 
mos los avances y volvíamos a rehacer las cosas para el PC, podíamos 
no llegar a terminarlo nunca. Decidimos seguir con el NeXT, 

En lo que se refería a la aplicación, el instinto me decía que tenía 
que seguir mi idea más amplia de crear un sistema global. Mi cabeza 
me recordó, sin embargo, que para atraer recursos también necesitaba 
una razón buena y visible para estar haciéndolo en el CERN. Yo no es- 
taba contratado por el CERN para crear el Web. En cualquier mo- 
mento, desde las altas esferas podían haber preguntado cómo estaba 
empleando yo el tiempo, y mientras que era bastante raro en el CERN 
impedir a la gente que continuase con sus propios proyectos, podrían 
haber puesto fin a mi proyecto informal. Sin embargo, era demasiado 
pronto para tratar de vender el Web como el sistema de documenta- 
ción definitiva que permitiría que todos los documentos del CERN, 
que estuvieran en proyectos en marcha o entre proyectos, se vincula- 
sen y fueran accesibles, especialmente dada la cantidad de sistemas de 
documentación fallidos que había. Parecía necesario dar pasos peque- 
ños pero cuantificables. Nuestro primer objetivo, por humilde que 
fuera como principio, tendría que ser el listín telefónico del CERN, 

El listín telefónico existía como base de datos en el viejo ordena- 
dor central del CERN. Bernd Pollermann, que conservaba esta infor- 
mación central y todas las demás, se encargaba de proporcionar este 
material a cada usuario en su sistema favorito. Conseguí convencer a 
Bernd de que el Web era justo lo que necesitaba para hacer su vida 
mucho más fácil. Si creaba un servidor, le dije, mandaríamos los nave- 
gadores a los escritorios de todo el mundo. Él aceptó. 

Hice que mi sencillo servidor se pusiese a funcionar en el ordena- 
dor central, luego lo partí en dos, de manera que las funciones esen- 
ciales de Internet referentes a HTTP fueran hechas por mi código (es- 
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crito en lenguaje C) y Bernd hizo el resto del servidor en su lenguaje 
favorito, “REXX”. Para que todos los documentos estuvieran dispo- 
nibles, sólo tuvo que aprender el HTML, lo que le llevó unas pocas 
tardes. Pronto todo el universo de sus ingenios de búsqueda, bases de 
datos y catálogos estaban disponibles como hipertexto. 

Esto nos llevó de vuelta a la búsqueda de un navegador. Empeza- 
mos metiendo el cliente modo-línea de Nicola en todo tipo de apara- 
tos, desde grandes ordenadores centrales, a través de estaciones de 
trabajo Unix, hasta simples DOS para PC. Éstos no eran buenos esca- 
parates para lo que era el Web, pero decidimos que, estuviera la gente 
en el aparato que estuviese, todo el mundo tendría acceso al Web. 
Éste era un gran paso, pero se consiguió con cierto sacrificio porque 
decidimos no perder tiempo en desarrollar el navegador modo-línea 
como editor. Sólo con que fuera capaz de leer documentos ya merecía 
la pena. Justificaba el tiempo que Bernd utilizó para poner en marcha 
sus servidores. Pero la gente se quedó con la idea del Web como un 
medio en el que unos pocos publicaban y muchos rastreaban. Mi vi- 
sión era un sistema en el que compartir lo que se sabía o pensaba de- 
bería ser tan fácil como aprender lo que otro ya sabía. 

Por muy mundana que fuera, esta primera presentación del Web 
fue, de un modo muy curioso, una aplicación genial. Mucha gente te- 
nía estaciones de trabajo con una ventana conectada permanentemen- 
te al ordenador central sólo para poder buscar números de teléfono. 
Nosotros enseñamos nuestro sistema por todo el CERN y la gente lo 
aceptó, aunque la mayoría no entendían por qué un simple programa 
ad hoc para conseguir números de teléfono no habría servido igual de 
bien. 

Naturalmente, no queríamos que nuestro invento, con todo su tre- 
mendo potencial, quedase encerrado en un nivel tan pedestre. Para 
ampliar los horizontes del Web, me dispuse a dar charlas y levar a 
cabo demostraciones. Así la gente podía ver algo “ahí en el Web” 
aparte del listín telefónico, y para poner en práctica lo que predicába- 
mos, Robert y yo seguimos documentando el proyecto en hipertexto 
en info.cern.ch. 

Lo que habíamos conseguido hasta entonces se basaba en una se- 
rie de principios clave aprendidos por medio de la experiencia. La 
idea de la universalidad era clave: la revelación básica era que un espa- 
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cio de información podía incluirlos todos, proporcionando una enor- 
me potencia y consistencia. Muchas de las decisiones técnicas surgían 
de esto. La necesidad de codificar el nombre o la dirección de cada 
objeto de información en una cadena URI era evidente. La necesidad 
de hacer de algún modo “iguales” a todos los documentos también 
era esencial. El sistema no podría dificultar los movimientos del usua- 
rio; una persona debería poder vincularse con igual facilidad con cual- 
quier documento donde fuera que estuviese almacenado. 

Ésta fue una revelación más importante de lo que parecía, porque 
los sistemas de hipertexto habían sido obras limitadas. Existían como 
bases de datos en un disquete o CD-ROM, con vínculos internos en- 
tre archivos. En el caso del Web, el vínculo externo es lo que le permi- 
titía convertirse realmente en “mundial”. El elemento importante de 
diseño consistiría en asegurar que cuando dos grupos hubieran empe- 
zado a usar el Web de manera completamente independiente en insti- 
tuciones distintas, una persona de un grupo podría crear un vínculo a 
un documento del otro con sólo un pequeño esfuerzo añadido, y sin 
tener que fusionar las dos bases de datos del documento o ni siquiera 
tener acceso al otro sistema. Si cualquier persona que estuviera en el 
Web pudiera hacer eso, entonces un único vínculo de hipertexto po- 
dría conducir a un enorme mundo sin límites. 


4, PROTOCOLOS 


REGLAS SENCILLAS PARA SISTEMAS GLOBALES 


La incompatibilidad entre ordenadores siempre ha sido un gran fasti- 
dio para todo el mundo, en el CERN y en todos los demás lugares en 
que se usan. El CERN tenía muchos grandes ordenadores de diversos 
fabricantes, y varios ordenadores personales también. El mundo real 
de la física de alta energía era un mundo de redes incompatibles, for- 
matos de discos y esquemas de codificación de caracteres, lo que con- 
vertía cualquier intento de transferir información entre ordenadores 
en algo generalmente imposible. Sencillamente, los ordenadores no se 
comunicaban unos con otros. La existencia del Web marcaría el fin de 
una era de frustración. 

Como si ésa no fuera ventaja suficiente, el Web también propor- 
cionaría una poderosa herramienta de gestión. Si las ideas, interaccio- 
nes y esquemas de trabajo de la gente podían ser seguidos usando el 
Web, entonces los análisis por ordenador podrían ayudarnos a obser- 
var patrones en nuestro trabajo y facilitar el que trabajásemos juntos 
superando los típicos problemas que se encuentran en cualquier gran 
organización. 

Una de las cosas hermosas acerca de la física es su búsqueda cons- 
tante para encontrar reglas simples que describan el comportamiento : 
de objetos muy pequeños y sencillos. Una vez encontradas, esas reglas 
pueden a menudo ir siendo aumentadas proporcionalmente para des- 
cribir el comportamiento de sistemas monumentales en el mundo 
real. Por ejemplo, entendiendo cómo interactúan dos moléculas de un 
gas cuando colisionan, los científicos, usando las matemáticas adecua- 
das, pueden deducir cómo billones y billones de moléculas de gas 
—como, por ejemplo, la atmósfera de la tierra— van a cambiar. Esto 
les permite analizar patrones globales de clima, y por tanto predecir el 
tiempo. Si las reglas que gobiernan los vínculos de hipertexto entre 
servidores y navegadores se mantuviesen simples, nuestro Web de 
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unos cuantos documentos podría crecer hasta convertirse en un Web 
global. 

La cuestión era definir las pocas reglas básicas y comunes del 

“protocolo” que permitiría a un ordenador hablar con otro, de modo 
que cuando lo hicieran todos los ordenadores de todas partes, los sis- 
temas floreciesen, no se vinieran abajo. Para el Web, esos elementos 
eran, en orden decreciente de importancia, identificadores de recur- 
sos universales (URIs), el Protocolo de Transferencia de Hipertexto 
(HTTP) y el Lenguaje Markup de Hipertexto (HTML). 

Lo que le costaba entender a la gente acerca del diseño era que no 
había nada más allá de los URls, HTTP y HTML. No había un ordena- 
dor central “controlando” el Web, ni un Web único en el que funcio- 
nasen esos protocolos, ni siquiera una organización en ninguna parte 
que “manejase” el Web. El Web no era una “cosa” física que existiese 
en determinado “lugar”. Era un “espacio” en el que la información 
podía existir. 

Yo le decía a la gente que el Web era como una economía de mer- 
cado. En una economía de mercado, cualquiera puede negociar con 
cualquiera, y no tienen que ir a una plaza de mercado para hacerlo. Lo 
que necesitan, sin embargo, son unas cuantas reglas con las que todo 
el mundo tiene que estar de acuerdo, como la moneda que se vaya a 
utilizar para el negocio y las reglas del comercio justo. Las reglas equi- 
valentes al comercio justo en el Web son reglas acerca de lo que signi- 
fica un URI como dirección, y el lenguaje que usan los ordenadores 
—HTTP— cuyas reglas definen cosas, como quién habla primero, y 
según qué turno hablan. Cuando dos ordenadores se ponen de acuer- 
do, pueden hablar, y luego tienen que encontrar una manera común 
de representar sus datos para poder compartirlos. Si usan el mismo 
software para documentos o gráficos, pueden compartirlos directa- 
mente. Si no, pueden traducirlos ambos a HTML. 

El principio fundamental que había detrás del Web era que una 
vez que alguien en alguna parte hiciera que un documento, base de 
datos, gráfico, sonido, vídeo o pantalla estuviesen disponibles en un 
determinado momento de un diálogo interactivo, estarían accesibles 
para todo el mundo (bajo autorización, naturalmente), con cualquier 
tipo de ordenador y en cualquier país. Y debería ser posible hacer una 
referencia —vínculo— a ese dato, para que otros pudieran encontrar- 
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lo. Éste era un cambio filosófico respecto al planteamiento de los an- 
teriores sistemas de ordenadores. La gente estaba acostumbrada a ir a 
buscar la información, pero rara vez se dirigían a otros ordenadores, y 
cuando lo hacían, tenían que citar una larga y compleja serie de ins- 
trucciones para conseguirla..Es más, en el caso del hipertexto global la 
gente tenía que cambiar, de pensar en instrucciones a pensar en térmi- 
nos de una simple serie identificativa —un URI— que contenía todos 
los detalles esenciales de forma compacta. 

Animar a la gente a que introdujera datos en el Web era a menu- 
do una cuestión de hacerles cambiar de perspectiva, de pensar en el 
acceso del usuario a ella no como una interacción con, digamos, un 
sistema de bibliotecas en línea, sino como una navegación a través de 
una serie de páginas virtuales en un espacio abstracto. En este con- 
cepto los usuarios podían señalar cualquier lugar y volver a él, y po- 
drían formar vínculos en cualquier lugar desde otro documento. 
Esto daría una sensación de persistencia, de existencia continuada, a 
cada página. También permitiría a la gente usar la maquinaria mental 
que poseen de modo natural para recordar lugares y rutas. Al ser ca- 
paz de relacionar cualquier cosa con la misma facilidad, el Web po- 
dría también representar asociaciones entre cosas que pueden pare- 
cer inconexas, pero por alguna razón comparten en realidad una 
relación. Esto es algo que el cerebro puede hacer fácil y espontánea- 
mente. Si un visitante entraba en mi despacho del CERN, y yo tenía 
una rama de lilas recién cortada en un rincón exhalando su maravi- 
lloso y fuerte perfume, su cerebro registraría una fuerte asociación 
entre el despacho y las lilas. Podían encontrarse con un lilo un día 
después en un parque y recordar de repente mi despacho. Un solo * 
clic: lilas... despacho. 

La comunidad de investigadores había usado vínculos entre do- 
cumentos en papel desde siempre: las tablas de contenidos, los índi- 
ces, las bibliografías y las notas son vínculos de hipertexto. En el 
Web, sin embargo, las ideas de investigación en vínculos de hipertex- 
to pueden seguirse en segundos, en lugar de hacerse en semanas, lla- 
mando por teléfono y esperando el correo. Y de pronto los científi- 
cos podían escapar de la organización secuencial de cada informe y 
bibliografía, para seguir y escoger un sendero de referencias que les 
pudiera interesar. 
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Pero el Web iba a ser mucho más que una herramienta para cientí- 
ficos. Naturalmente, para que un sistema internacional de hipertexto 
mereciera la pena, mucha gente tendría que mandar información. El 
físico no encontraría gran cosa sobre quarks, ni el estudiante de arte 
sobre Van Gogh, si no hubiera mucha gente y muchas organizaciones 
que ofrecieran sus informaciones para empezar. No sólo eso, sino que 
gran parte de la información —desde los números de teléfono hasta 
las ideas actuales y el menú de hoy— está en constante cambio, y sólo 
sirve de algo si está actualizada. Eso quiere decir que cualquiera (que 
esté autorizado) debería poder publicar y corregir información y cual- 
quiera (que esté autorizado) debería poder leerla. No podría haber un 
control centralizado. Para publicar información, habría que ponerla 
en cualquier servidor, un ordenador que compartiese sus recursos con 
otros ordenadores, y la persona que lo manejase definiría quién podía 
contribuir, modificar y acceder al material que hubiera en él. La infor- 
mación era leída, escrita o editada por un cliente, un programa de or- 
denador, como por ejemplo un navegador/editor, que pidiera acceso a 
un servidor. 

Existían ya varios protocolos para transferir datos en Internet, so- 
bre todo NNTP para Network News y FTP para archivos. Pero estos 
no hacían la negociación que yo necesitaba, entre otras cosas. Por tan- 
to definí HTTP, un protocolo bastante sencillo para llegar a una pági- 
na Web lo bastante rápido como para rastrear hipertexto. El objetivo 
era una aparición de una décima de segundo aproximadamente, así 
que no había tiempo para conversación. Tenía que ser: “Traiga este 
documento” y “¡Aquí está!”. 

Naturalmente, si hubiera insistido en que todo el mundo usara 
HTTP, esto también habría estado en contra del principio de la obli- 
gación mínima. Si el Web tenía que ser universal, debería ser tan poco 
obligatorio como fuera posible. Contrariamente al ordenador NeXT, 
el Web aparecería como un conjunto de ideas que se pudiera adoptar 
individualmente en combinación con partes ya existentes o futuras. 
Aunque el HTTP iba a ser más rápido, ¿quién era yo para decir que la 
gente abandonase los grandes archivos de datos accesibles desde los 
servidores FTP? 

La clave para resolver esto era el diseño de URL. Es la innovación 
fundamental del Web, porque es la única especificación que cualquier 
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programa Web, cliente o servidor en cualquier parte usa cuando se si- 
gue cualquier vínculo. Una vez que un documento tenía un URL, po- 
día ser enviado a un servidor y encontrado por un navegador. 

Escondido detrás de una palabra subrayada que indica un vínculo 
de hipertexto está el documento de destino URI, que dice al navegador 
dónde encontrar el documento. Una dirección URI tiene diferentes 
partes, algo así como el código de cinco dígitos usado por el sistema de 
correos de Estados Unidos. Los tres primeros números designan una 
región geográfica: un pueblo o parte de una ciudad o condado. Los dos 
números siguientes definen una parte muy específica de esa región, 
como unas cuantas manzanas de una ciudad. Eso lleva al correo a una 
oficina de correos local. Los carteros usan el número de la calle o apar- 
tado para llevar el correo a su destino final. 

Las barras se usan en una dirección URI para delinear sus partes. 
Las primeras letras del URI dicen al navegador qué protocolo usar 
para mirar el documento, ya sea HTTP, FTP o uno de los otros. En la 
dirección bttp://w1ww.foobar.com/doc1, el www.foobar.com define el 
servidor real donde esos documentos existen. Doc1 es un documento 
específico en el servidor 1www.foobar.com (puede haber cientos, cada 
uno con un nombre diferente tras la barra simple). Las letras que hay 
antes de la doble barra significan el protocolo de comunicaciones que 
usa ese servidor. 

La gran diferencia entre el URI y los sistemas postales, sin embar- 
go, es que mientras que en alguna parte hay una gran tabla con todos 
los códigos postales, la última parte del URI significa cualquier cosa 
que un servidor determinado quiera que signifique. No tiene que ser 
un nombre de archivo. Puede ser el nombre de una tabla, el nombre 
de una cuenta, las coordenadas de un mapa, o lo que sea. El cliente 
nunca trata de imaginar lo que significa: sólo lo pide. Este importante 
hecho permitía que una enorme diversidad de tipos de sistemas de in- 
formación coexistiera en el Web. Y permitía al Web recoger inmedia- 
tamente todo el contenido NNTP y FTP de Internet. 

Al mismo tiempo que yo estaba desarrollando el Web, iban apare- 
ciendo otros sistemas de información basados en Internet. Brewster 
Kahle, de Thinking Machines, había estructurado su último y potente 
procesador paralelo. Ahora veía un mercado para los grandes apara- 
tos como máquinas de búsqueda y diseñó el protocolo Wide Area In- 
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formation Servers [Servidores de Información de Amplia Zona] 
(WAIS) para permitirles formar un sistema semejante al Web pero sin 
vínculos; sólo aparatos de búsqueda. 

- Clifford Newman, del Instituto de Ciencias de la Información, 
propuso su sistema de archivo distribuido Próspero como un sistema 
de información basado en Internet, y Mark MeCahill y sus colegas de 
la Universidad de Minnesota estaban desarrollando un sistema de in- 
formación para todo el campus llamado gopbher [ardilla], nombre de la 
mascota de la universidad. Para destacar que todos los sistemas de in- 
formación podían ser incorporados al Web, definí dos nuevos prefijos 
URI que podían aparecer antes de la doble barra —“gopher:” y 
“wais:”—, que darían acceso a esos espacios. Ambos sistemas despe- 
garon mucho más rápido que el Web y a mí me preocupó mucho en 
aquel momento que pudieran ahogarla. 

El HTTP tenía una característica llamada negociación de formato 
que permitía a un cliente decir qué clase de formato de datos podía 
manejar, y permitía al servidor devolver un documento en cualquiera 
de esas clases de formato. Esperaba que existieran toda clase de for- 
matos de datos en el Web. También me parecía que tenía que haber 
una lingua franca común y básica que cualquier ordenador pudiera 
llegar a entender. Esto sería un sencillo lenguaje de hipertexto que se- 
ría capaz de proporcionar una navegación básica de hipertexto, me- 
nús y documentación sencilla como archivos de ayuda, resúmenes de 
reuniones y mensajes de correo, esto es, el 95% de la vida diaria de la 
mayoría de la gente. Ése sería el HTML, el Hypertext Markup Lan- 
guage. 

Yo esperaba que el HTML fuera la urdimbre y la trama del Web, 
pero que todo tipo de documentos —vídeo, diseño asistido por orde- 
nador, sonido, animación y programas ejecutables— fueran los hilos 
coloreados que contendrían gran parte del contenido. Acabaría resul- 
tando que el H'T'ML se volvería sorprendentemente popular también 
con respecto al contenido. > 

El H'T'ML es una forma sencilla de representar el hipertexto. Una 
vez que el URI de un documento dice a un navegador que hable 
HTTP con el servidor, luego cliente y servidor tienen que ponerse de 
acuerdo en el formato de los datos que van a compartir, para que pue- 
dan descomponerse en paquetes que ambos puedan entender. Si am- 
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bos conocen los archivos de WordPerfect, por ejemplo, podrían inter- 
cambiar documentos de WordPerfect directamente. Si no, pueden in- 
tentar ambos traducir a HTML por defecto y mandar documentos de 
esa manera. Había varias reglas básicas de diseño que guiaban el 
HTML, y algunas opciones pragmáticas, incluso políticas. Una regla 
filosófica era que el HTML debía contener la estructura de un docu- 
mento de hipertexto, pero no detalles de su presentación. Ésta era la 
única forma de que apareciese razonablemente en cualquiera de una 
amplia gama de pantallas diferentes y distintos tamaños de papel. 
Como sabía que iba a ser difícil convencer a todo el mundo para que 
usase un nuevo sistema de información global, quería hacer disponi- 
bles todos los grupos que pudiese. Había una familia de lenguajes de 
markup (descripción de documentos), el lenguaje markup estándar 
generalizado (SGML), que ya prefería la mayoría de la comunidad do- 
cumentalista del mundo, y que por entonces se consideraba el único 
estándar potencial de documentos entre la comunidad del hipertexto. 
Desarrollé el HTML para que pareciera un miembro de esa familia. 

Diseñar el HTML para que se basara en el SGML hizo que se des- 
tacara uno de los temas del desarrollo del Web: la interrelación cons- 
tante entre la astuta decisión diplomática y la cosa técnica y limpia que 
había que hacer. El SGML usaba un sistema sencillo para indicar ins- 
trucciones o “etiquetas”, que consistía en poner una palabra entre co- 
millas de ángulo (como en <»1> para señalar el encabezamiento prin- 
cipal de una página), pero también tenía muchas características 
oscutas y extrañas que no se entendían bien. De todos modos, por en- 
tonces, el Web necesitaba apoyo y comprensión por parte de cada co- 
munidad que pudiera llegar a estar implicada, y en muchos sentidos la 
comunidad SGML proporcionaba una base valiosa. 

También en el CERN el SGML era una elección diplomática. EL 
SGML se usaba en los aparatos IBM del CERN con un conjunto pat- 
ticular de etiquetas que estaban encerradas en comillas de ángulo, así 
que el HTML usaba las mismas etiquetas siempre que le era posible. 
Limpié bastante el lenguaje, pero aún así seguía siendo reconocible. 
Escogí esta dirección para que cuando un empleado del CERN viera 
las comillas de ángulo del HTML, tuviera la sensación de: $2, yo puedo 
hacerlo. De hecho, el HTML era incluso más fácil de usar que la ver- 
sión SGML del CERN. La gente que promocionaba el sistema SGML 
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en el CERN podían ser posiblemente figuras poderosas en la elección 
de las futuras direcciones del CERN, y yo quería que se sintieran con- 
tentos con el Web. 

Nunca pretendí que el código fuente del HTML (lo que iba entre 
comillas de ángulo) lo viéran los usuarios. Un navegador/editor per- 
mitiría a un usuario que viera o editara simplemente el lenguaje de una 
página de hipertexto, como si estuviera usando un procesador de tex- 
tos. La idea de pedirle a la gente que escribiera las comillas de ángulo 
a mano era para mí, y supuse que para muchos, tan inaceptable como 
pedir a uno que preparase un documento de Microsoft Word escri- 
biendo su formato binario codificado. Pero la legibilidad humana del 
HTML fue una bendición inesperada. Para mi sorpresa, la gente se fa- 
miliarizó enseguida con las etiquetas y empezó a escribir sus propios 
documentos HTML directamente. 


A medida que las piezas técnicas se iban poniendo lentamente en su 
lugar, Robert y yo aún teníamos que enfrentarnos a una serie de asun- 
tos políticos que nos dieron más de un dolor de cabeza. En primer lu- 
gar, el Web seguía sin ser todavía un proyecto formal. En cualquier 
momento, un jefe de la división de Computing and Networking podía 
decirme que detuviese el trabajo, ya que no era parte de ningún pro- 
yecto y podía haber sido considerado inapropiado para el CERN. 

Durante ocho meses, Robert, Nicola y yo afinamos las piezas bási- 
cas del Web y tratamos de promocionar lo que estábamos creando. 
Esbozamos un plan de trabajo para la división de Electronics and 
Computing for Physics, donde estaba Robert, para intentar conseguir 
fondos de ellos, pero nadie respondió. Según eso, mientras desarrollá- 
bamos la tecnología y tratábamos de promocionarla entre nuestros co- 
legas, seguíamos teniendo que seguir trabajando casi en secreto. 

El otro problema al que nos enfrentábamos era sencillamente el 
clima en el CERN. Había un fondo constante de gente que promocio- 
naba ideas para nuevos sistemas de software. Había competitividad 
entre los sistemas creados dentro de los propios grupos de experimen- 
tación: software para llevar a cabo un experimento de física, pero tam- 
bién para cualquier cosa, desde manejar correo electrónico y organi- 
zar documentos hasta hacer funcionar la máquina de Coca Cola. 
Había competitividad acerca de qué Web usar, entre ellas la DECnet, 
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el Internet y lo que cualquier cosa hecha en la casa pudiera justificar. 
Con tantos ingenieros y físicos creativos en un solo lugar, las innova- 
ciones eran constantes. Al mismo tiempo, era evidente que el CERN 
no podía consentir que todo el mundo crease un software único para 
cada función. : ; 

Robert y yo tuvimos que hacer ver nuestra idea como original, y 
que además permitiría al CERN dar un salto hacia delante. En lugar 
de pavonearnos con nuestro nuevo sistema para compartir cósmica- 
mente la información, decidimos intentar convencer a la gente de que 
les estábamos ofreciendo una manera de extender sus sistemas de do- 
cumentación ya existentes. Ésta era una noción concreta y potencial- 
mente prometedora. Más tarde podríamos hacerles entrar en el sueño 
del hipertexto global. Nuestro argumento era que todo el mundo po- 
dría seguir almacenando datos en la forma que quisiera, y manejarlos 
como quisiera. El Web sencillamente ayudaría a la gente a mandar y 
recibir información entre ellos, sin que importase el sistema operativo 
o los formatos que usase su ordenador. Lo único que tenían que hacer 
era seguir el mismo esquema sencillo de envío URL No “tenían que” 
usar el HTTP o el HTML, pero esas herramientas estaban ahí si topa- 
ban con un problema de incompatibilidad. 

Al hacer notar esos puntos, también señalamos que usar el HTML 
era fácil, ya que era muy parecido al SGML. Pude haber insistido de- 
masiado en ese punto de vista, sin embargo. Aunque el SGML había 
sido adoptado como estándar por el ISO, no estaba bien definido 
como lenguaje de ordenador. También tuve un fuerte rechazo por par- 
te de mucha gente que insistía en que podía ser demasiado lento. Tuve 
que explicar que la única razón por la que el SGML era lento era por 
el modo en que históricamente se había llevado a cabo. Aún así, a me- 
nudo tuve que hacer demostraciones del programa World Wide Web 
leyendo un archivo HTML y mostrándolo en la pantalla en una frac- 
ción de segundo antes de que la gente se convenciera. 

Algunas personas estaban intrigadas, pero muchas nunca acepta- 
ron mis argumentos. En lugar de entrar en debates inútiles, seguí ade- 
lante con el HTML y enseñé el Web por ahí todo lo que me fue posi- 
ble. Robert y yo organizamos algunos coloquios abiertos a todos los 
de nuestros departamentos. También hablamos de ello a la gente a la 
hora del café. Ocasionalmente, un grupo de gente preparándose para 
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hacer un experimento llamaba para decir que estaban hablando de su 
sistema de documentación, y preguntaba si podía acercarme y darles 
mi opinión acerca de ello. Me encontraba con un grupo de unas veinte 
personas y les mostraba el Web, que quizá no usasen esa vez, pero que 
la vez siguiente ya conocetían y un nuevo servidor iría silenciosamente 
tomando forma. 0 , 

Mientras tanto, Robert y yo seguíamos metiendo información en 
el servidor info.cern.ch, mejorando constantemente la guía básica 
para los recién llegados que decía cómo meterse en el Web, con espe- 
cificaciones e indicadores del software disponible. 

Seguí tratando de conseguir que otras organizaciones convirtiesen 
sus sistemas de hipertexto en clientes del Web. Descubrí una potente 
herramienta del SGML llamada Grif, desarrollada por un grupo de 
investigación del laboratorio francés INRÍA, que funcionaba con má- 
quinas Unix y PCs. Una compañía con el mismo nombre, Grif, se había 
puesto en marcha en la cercana Grenoble, y yo tenía la esperanza de 
que sus líderes pudieran pensar en desarrollar un navegador Web que 
también pudiera editar. Tenían un editor de hipertexto muy hermoso 
y sofisticado; hacía gráficos, hacía textos en múltiples fuentes, mostra- 
ba la estructura del SGML y el documento formateado en dos venta- 
nas diferentes, y permitía que se hicieran cambios en cualquiera de 
ellos. Era perfecto. Lo único que faltaba era que no funcionaba en In- 
ternet. La misma historia. 

Traté de convencer a la gente de Grif para que añadiesen el soft- 
ware necesario para mandar y recibir archivos por Internet, de mane- 
ra que su editor se convirtiese también en un navegador Web. Les dije 
que yo les daría directamente el software; no tenían más que usarlo. 
Pero dijeron que el único modo que tenían de hacerlo era si podíamos 
conseguir que la Comisión Europea financiase el desarrollo. No que- 
rían arriesgarse. Me quedé muy frustrado. Había un grupo creciente 
de personas que estaban muy emocionadas con las posibilidades del 
World Wide Web, y allí teníamos la tecnología para un auténtico na- 
vegador/editor de hipertexto casi totalmente desarrollada, pero no 
podíamos dar el salto. Conseguir fondos de la Comisión supondría es- 
perar dieciocho meses más. Esta manera de pensar, reflexioné, era 
tristemente diferente de la actitud mucho más emprendedora de los 
americanos, que desarrollaban cualquier cosa en el garaje sólo para di- 
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vertirse, y se preocupaban por encontrar fondos sólo cuando la cosa 
funcionaba. 

En marzo de 1991, mandé el programa World Wide Web a un nú- 
mero limitado de personas en el CERN que tenía ordenadores NeXT. 
Esto les permitiría al menos escribir su propio hipertexto y poder dis- 
poner de la información Web que Robert y yo estábamos metiendo en 
info.cern.ch. 

Se corrió la voz en la comunidad de físicos de alta energía, fomen- 
tada por la influencia polinizadora de los viajes. En mayo de 1991 
Paul Kunz llegó de una visita del Acelerador Lineal Stanford (SLAC) 
en Palo Alto. Al igual que yo, era un entusiasta del NeXT desde el 
principio y había venido al CERN a trabajar en unos programas del 
NeXT. Como tenía el ordenador adecuado, estaba en posición de usar 
el Web directamente, y le encantó. 

Cuando Paul volvió de SLAC, compartió el Web con Louise Ad- 
dis, la bibliotecaria que revisaba todo el material producido por 
SLAC. A ella le pareció un regalo del cielo para su sistema de bibliote- 
ca bastante sofisticado pero sometido al ordenador central, y un modo 
de poner a disposición de los físicos de todo el mundo el sustancioso 
catálogo interno de SLAC de documentos en línea. Louise convenció 
a un colega de que desarrollase herramientas para ella para escribir el 
programa adecuado, y con los ánimos de Louise, SLAC puso en mar- 
cha el primer servidor Web fuera de Europa. 

Al ver que los físicos de alta energía de SLAC estaban tan entu- 
siasmados con el Web, nos volvimos más agresivos con la promoción 
dentro del CERN. En mayo, Mike Sendall nos proporcionó una apari- 
ción delante del comité C5, que siempre estaba rebuscando en infot- 
mática y comunicaciones, para que explicásemos lo útil que podía ser 
el Web, para que la dirección siguiera justificando el trabajo. Robert y 
yo también escribimos un informe, “Hipertexto en el CERN”, que 
trataba de demostrar la importancia de lo que estábamos haciendo. 

Lo que esperábamos era que alguien dijera: “¡Oh! ¡Esto va a ser la 
piedra angular de las comunicaciones de los físicos de alta energía! 
Unirá a toda la comunidad en los próximos diez años. Aquí están cua- 
tro programadores para trabajar en el proyecto y aquí está su contacto 
con los Sistemas de Gestión de Información. Cualquier otra cosa que 
necesiten, pídannoslo”. Pero aquello no ocurrió. 
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En junio dimos charlas y demostraciones dentro del CERN, y es- 
cribimos acerca del Web en el periódico interno del CERN. Como se- 
guía sin tener más personal, estaba llevando más tiempo del que yo 
había esperado el conseguir que funcionase la versión NeXT en los 
PC, los Macs y los Unix. 

Seguía esperando que, a fuerza de correr la oz, pudiésemos atraer 
la atención de más programadores. Como era raro que esos programa- 
dores fuesen físicos de alta energía, en agosto saqué tres cosas —el 
WorldWideWeb para NeXT, el navegador modo-línea y el servidor bá- 
sico para cualquier aparato— fuera del CERN, haciendo que todos 
estuvieran disponibles en Internet. Mandé una nota a varios grupos 
de noticias de Internet, entre ellos principalmente a alt.hypertext, que 
era para entusiastas del hipertexto. Por desgracia, seguía sin haber 
muchos usuarios que pudieran verlo a menos que tuvieran un NeXT, 

Sacar el Web en alt.hypertext fue un acontecimiento decisivo. Co- 
locó a el Web ante una comunidad académica muy crítica. Empecé a 
recibir e-mails de gente que trataba de instalar el software. Me infor- 
maban sobre virus, y decían “¿no estaría bien que...?”. De vez en cuan- 
do llegaba un “Eh, acabo de instalar un servidor y está como muerto. 
Aquí va la dirección”. 

Con cada nuevo mensaje yo metía en info.cern.ch un vínculo de 
hipertexto al nuevo sitio web, para que otros que visitasen el sitio 
CERN pudiesen vincularse con esa dirección también. A partir de en- 
tonces, la gente interesada en Internet proporcionaba la alimentación, 
la estimulación, las ideas, contribuían con fuentes de códigos y con 
ayuda moral que habría sido difícil de encontrar cerca. La gente que 
estaba en Internet construyó el Web, al auténtico estilo popular. 

Durante varios meses fue principalmente la comunidad del hiper- 
texto la que estaba usando el Web, y la comunidad NeXT, porque es- 
taban interesados en software que funcionara en la plataforma. A me- 
dida que pasaba el tiempo, bastante gente en línea acordó que debería 
haber un grupo de noticias que compartiese información sobre el 
Web, así que pusimos en marcha uno que se llamaba comp.infosys- 
tems.www. Contrariamente a alt.hypertext, éste era un grupo de noti- 
cias importante, creado tras un voto global de aprobación. 

Otro paso pequeño pero efectivo para aumentar la difusión del 
Web se dio cuando abrí un servidor vía telnet público en info.cern.ch. 
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Telnet era un protocolo que ya existía, que también funcionaba en In- 
ternet y que permitía a una persona que estuviese usando un ordena- 
dor abrir una sesión de línea de comandos interactiva en otro ordena- 
dor. Cualquiera que usase un programa de telnet para registrarse en 
info.cern.ch, se conectaría directamente al navegador modo-línea. 
Este enfoque tenía la desventaja de que el usuario vería el Web como 
un sistema sólo de texto y sólo de lectura. Pero abriría el Web a millo- 
nes de personas que no podían instalar un navegador Web en su apa- 
rato. Eso significaba que alguien que abriese un servidor Web podía 
decir “telnet a info.cern.ch y teclear “ir a www.foobar.com””, lo que era 
mucho más fácil que pedirles que instalasen un navegador Web. La 
página inicial vista por los usuarios de este servicio público incluiría 
vínculos con las instrucciones para descargar su propio navegador. 
Años más tarde tendríamos que retirar este servicio, porque el aparato 
no podía soportar la carga, pero para entonces ya habría cumplido su 
función. : 

Lo más valioso que ocurrió fue que la gente que veía el Web y se 
daba cuenta de la sensación de oportunidad sin límites, empezaba a 
instalar el servidor y a enviar información. Luego añadían vínculos a 
sitios relacionados que les parecían complementarios, o sencillamente 
interesantes. Gente de todo el mundo empezaba a utilizar el Web. Co- 
menzaron a llegar mensajes de gestores de sistemas: “Eh, creo que les 
podrá interesar. Acabo de instalar un servidor Web”. 


Nicola tuvo que abandonar la tarea en agosto de 1991, pues acababa 
su internado y tenía que volver a la universidad. Fiel a la forma, Ben 
Segal encontró otra joya para sustituirla. Jean-Francois Groff estaba 
lleno de entusiasmo por la idea del Web, y por el NeXT. Llegó al 
CERN procedente de Francia gracias a un programa de “coopera- 
ción” que permitía a la gente joven más brillante, en lugar de pasar un 
año de servicio militar, trabajar durante dieciocho meses en una orga- 
nización extranjera como voluntario. 

Por entonces habíamos llegado a otro difícil punto decisivo acerca 
de la codificación. Gran parte de la codificación del NeXT estaba en 
lenguaje objective-C. Queríamos que la gente lo usase ampliamente, 
pero los compiladores de objective-C eran raros. El lenguaje común 
para programas fáciles de portar a otros ordenadores seguía siendo C, 
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así que si queríamos que fuera posible para más gente en Internet de- 
sarrollar software del Web, tenía sentido convertirlo a C, ¿Debería, en 
el interés de la conveniencia práctica, convertir toda mi codificación 
objective-C al menos potente C, o debería conservar la plataforma de 
desarrollo más potente que tenía ya? 

El factor decisivo fue que el navegador modo-línea de Nicola esta- 
ba escrito en €. Decidí hacer un sacrificio y, mientras mantenía el esti- 
lo orientado a objeto de mi diseño, disminuí (downgraded) toda la co- 
dificación común que pude exportar del WorldWideWeb del NeXT a 
un lenguaje € más común. 

Esto suponía mucho trabajo, pero abría nuevas posibilidades y 
también permitía llevar a cabo una cierta limpieza mientras avanzaba. 
Jean-Francois llegó en el momento justo. Durante semanas nos senta- 
mos espalda contra espalda en nuestro despacho produciendo códi- 
gos, discutiendo sobre los interfaces entre los módulos, hablándonos 
por encima del hombro. 

—+¿Puedes darme un método para encontrar el último elemento? 

—Vale. Llámalo “últimoElemento”. 

— Muy bien. ¿Parámetros? 

—L ista, tipo de elemento. Ya sabes. 

—;¡ Gracias! 

Sacamos un código específico para el Web y también tuvimos que 
duplicar algunas de las herramientas del maletín de herramientas del 
NeXT. El resultado, ya que una colección de trozos de código para 
uso general se llama una biblioteca (library), lo llamamos “libwww”. 

Por desgracia, la política del CERN con los cooperantes como 
Jean-Francois era que tenían que marcharse cuando se agotaba su: 
tiempo de estancia. Veían un posible peligro de que el personal abusa- 
se del programa como una forma de reclutar gente y prohibían el em- 
pleo de cualquiera de esas personas en modo alguno en el futuro. 
Cuando Jean-Francois acabó su período, intentamos todo lo que pu- 
dimos para que le permitieran seguir trabajando con el Web, pero fue 
imposible. Se marchó y puso en marcha una compañía en Ginebra, 
infodesign.ch, probablemente la primera consultoría de diseño del 
Web. 

Mientras tanto, yo había empezado a crear registros del número 
de veces a las que se accedía a las páginas del primer servidor del Web, 
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info.cern.ch, en el CERN. En julio y agosto de 1991 hubo entre diez y 
cien “hits” (páginas visitadas) cada día. 

Este progreso era lento, pero estimulante. Comparé el esfuerzo de 
poner en marcha el Web con el que era necesario para poner en mar- 
cha un trineo: todo el mundo tiene que empujar con fuerza durante 
un tiempo que parece muy largo, pero antes o después, el trineo se 
pone en marcha y todo el mundo salta sobre él, 

En octubre instalamos “pasarelas” (gateways) a dos populares ser- 
vicios de Internet. Un pórtico era un pequeño programa, como el que 
abría el servidor del ordenador central de Bernd, que ponía a nuestra 
disposición otro mundo más como parte del Web. Una pasarela iba al 
sistema de ayuda en línea del sistema operativo de Digital VAX/VMS. 
Otra, al WAIS de Brewster Khale para bases de datos. Esto se hizo 
para añadir incentivos a que cualquier individuo particular instalase 
un navegador. VMS tenía como objetivo la comunidad de físicos, y 
WAIS la comunidad de Internet. También puse en marcha una lista de 
correo en línea, www-talkGinfo.cern.ch, para discusiones técnicas, 
como un foro para la creciente comunidad. 

Tratando siempre de equilibrar el esfuerzo que poníamos en con- 
seguir apoyo de diferentes grupos, Robert y yo decidimos que ahora 
teníamos que promocionar el Web con empeño entre la comunidad 
del hipertexto. Iba a haber una gran conferencia en diciembre, Hy- 
pertext 91, en San Antonio. La gente más importante del sector iba a 
estar allí, incluyendo a Doug Engelbart, que había creado el ratón y 
un sistema de hipertexto auxiliar allá por los sesenta. Aunque era difí- 
cil encontrar tiempo, compusimos un informe para ello, pero no sirvió 
de mucho. Fue rechazado, en parte porque no estaba terminado, y no 
hacía bastantes referencias al trabajo en ese campo. Al menos uno de 
los que lo revisaron también pensó que el sistema propuesto violaba 
los principios arquitectónicos sobre los que los sistemas de hipertexto 
habían funcionado hasta entonces. 

De todos modos, pudimos convencer a los organizadores de la 
conferencia de que nos dejasen llevar a cabo una demostración. Ro- 
bert y yo volamos hasta San Antonio con mi ordenador NeXT y un 
módem. No pudimos conseguir acceso directo a Internet en el hotel. 
De hecho, la comunidad del hipertexto estaba tan apartada de la co- 
munidad de Internet que no podíamos establecer ninguna conexión. 
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¿Cómo podríamos hacer una demostración del Web si no podíamos 
marcar info.cern.ch? Robert descubrió una forma. Convenció al di- 
rector del hotel de que instalase una línea telefónica en el vestíbulo 
junto a la sala de reuniones. Eso nos permitiría conectar el módem. 
Ahora necesitábamos acceso a Internet. Durante nuestro viaje en taxi 
desde el aeropuerto, Robert había preguntado al taxista que cuál era 
la universidad más cercana, y descubrió que era la universidad de Te- 
jas, en San Antonio. Robert llamó a la universidad y descubrió a algu- 
nas personas que entendían de Internet y quizá del Web, y accedieron 
a dejarnos usar su servicio de conexión para que pudiéramos llamar al 
ordenador del CERN, 

El siguiente desafío fue conseguir que el módem suizo que había- 
mos traído funcionase con el sistema eléctrico americano. Compra- 
mos un adaptador de potencia que admitiese 110 voltios (en lugar de 
los 220 de Suiza). Naturalmente, no teníamos el enchufe adecuado 
para conectarlo al módem. Tuvimos que desmontar el módem, pedir 
prestado un soldador en el hotel (¡Robert se sintió muy orgulloso de 
esta hazaña!) y conectarlo directamente. Robert consiguió conectarlo 
todo, y funcionó. 

No teníamos una conexión real con Internet, sólo un “login” [en- 
trada en el sistema] Unix, así que sólo pudimos mostrar el programa 
gráfico World Wide Web funcionando con datos locales. De todos 
modos, pudimos demostrar el navegador modo-línea funcionando. 
Éramos las únicas personas de toda la conferencia haciendo algún 
tipo de conexión. Sobre la pared de la sala de demostraciones estaban 
colocados los títulos de los proyectos, encima de cada cabina, y sólo 
uno de ellos tenía alguna referencia al World Wide Web: el nuestro. : 

En la misma conferencia, dos años más tarde, en la misma pared, 
cada proyecto que se exhibía tenía algo que ver con el Web. 


5. GLOBALIZACIÓN 


A medida que el Web iba extendiéndose lentamente por todo el mun- 
do, empecé a preocuparme porque la gente que estuviera establecien- 
do servidores no usase el HTTP, el HTML y los URls de forma con- 
sistente. Si no lo hacían, podían introducir inintencionadamente 
bloqueos que impidieran funcionar a los vínculos. 

Cuando volví al CERN de San Antonio, escribí varias páginas web 
más acerca de las especificaciones web. Las pondría al día cuando lle- 
gasen buenas ideas de otros usuarios en la lista de correo www-talk. 
Mientras que eso era un principio, quería abrir la tecnología del Web 
para que se revisara más a fondo. Como todo hasta la fecha se había 
hecho por Internet, y gran parte de ello suponía usar protocolos de 
Internet, me parecía que el lugar en el que había que poner en marcha 
el proceso era la Internet Engineerin Task Force (1ETF) [Destaca- 
mento de Ingeniería de Internet], un foro internacional de gente que 
mantenía correspondencia principalmente a través de listas de e-mail, 
pero que también se veían físicamente tres veces al año. El IETF fun- 
ciona sobre un principio de participación abierta. Cualquiera que esté 
interesado en cualquier grupo de trabajo puede contribuir, 

Como buen ingeniero de software, yo quería normalizar por sepa- 
rado cada una de las tres especificaciones fundamentales de la Red: el 
esquema de direcciones URI, el protocolo HTTP por medio del cual 
los ordenadores hablaban unos con otros, y el formato HTML de do- 
cumentos de hipertexto. Lo más importante de todo esto era la espe- 
cificación URI 

La siguiente reunión del IETF iba a tener lugar en marzo de 1992 
en San Diego, y yo fui a ver cómo funcionaban las cosas, y cómo poner 
en marcha un grupo de trabajo. La respuesta vino de Joyce Reynolds, 
que dirigía una sección del IET. Dijo que primero tenía que tener 
una reunión de interesados (“pájaros del mismo plumaje”) pata deci- 
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dir si había que establecer un grupo de trabajo. Si había consenso, la 
gente que asistiera a la sesión podía organizar un grupo de trabajo que 
empezara a funcionar durante la siguiente reunión del IETF. El grupo 
de trabajo podría editar una especificación y convertirla en un están- 
dar. La reunión siguiente se celebraría en julio en Boston. 

Las reuniones del TEFT se caracterizaban por la gente que iba en 
camiseta y vaqueros, y a veces sin zapatos. Se encontraban en diversas 
habitaciones pequeñas y hablaban con excitación. Lo más importante 
eran las redes, naturalmente. En comparación con Ginebra en marzo, 
era para mí un placer sentarme con amigos al aire libre, en la soleada y 
cálida San Diego. : 

Tomando un día un café, estaba sentado a una mesa blanca metáli- 
ca al aire libre, charlando con Larry Massinter, de Xerox PARC y Ka- 
ren Sollins, que había sido estudiante de Dave Clark, el profesor del 
Laboratorio de Ciencias Informáticas del MIT que estaba muy impli- 
cado en el diseño del protocolo TCP que había permitido el uso prác- 
tico del Internet. Karen se había quedado en el MIT para seguir con 
un proyecto llamado Infomesh, para crear un modo de que los orde- 
nadores intercambiaran informaciones sobre dónde encontrar docu- 
mentos en los que ambos estuvieran interesados. 

Larry y Karen me preguntaron qué iba a hacer yo a continuación. 
Les dije que estaba pensando en tomarme un año sabático. Llevaba 
siete años en el CERN y necesitaba un descanso y nuevas perspectivas. 
Necesitaba pensar en dónde llevarme a mí mismo y al Web. Después 
de volver al CERN, tanto Larry como Karen llamaron cada uno por su 
lado con ofertas para ir a visitarlos si me marchaba. Podía unirme a 
Karen como investigador visitante en el MIT o a Larry como visitante 
en Xerox PARC. 

Las dos invitaciones eran atrayentes, porque ambas instituciones 
eran muy respetadas y cualquiera de las dos podía darme una visión 
muy necesaria de lo que estaba pasando en Estados Unidos más que 
en Europa, y en tecnología de información más que en física. 

Animado por el entusiasmo de gente como Larry y Karen, Robert 
y yo mandamos notas sobre el Web en más grupos de noticias de In- 
ternet. Pero nos vimos frustrados por el hecho de que el uso del Web 
dentro del CERN era muy pequeño. Estábamos en un difícil equili- 
brio, entre dedicar nuestro tiempo a apoyar a los usuarios dentro del 
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CERN a riesgo de descuidar al mundo exterior, y perseguir el objetivo 
de la interactividad global a riesgo de ser expulsados por no ceñirnos 
a los intereses del CERN. 

Por entonces el Web consistía en un pequeño número de servido- 
res, siendo info.cern.ch el más interconectado con el resto. Contenía 
una lista de servidores que hasta cierto punto podían coordinar a la 
gente que estaba metiendo información en el Web. Cuando la lista se 
hizo mayor, necesitaba ser organizada, así que hice dos listas, según la 
localización geográfica y según el tema. A medida que llegaban más 
servidores, era emocionante ver cómo los temas se iban llenando. Art- 
hur Secret, otro estudiante, se unió a mí durante un tiempo y estable- 
ció las listas dándoles la forma de lo que llamamos la Biblioteca Vir- 
tual, con una estructura de árbol que permitía a la gente encontrar 
COSas. 

Parte de la razón de que el Web no se estuviera usando mucho en 
el CERN —o extendiéndose más fuera del CERN, la verdad— era la 
falta de clientes de señalar-y-cliquear (navegadores gráficos) para lo 
que no fuera el NeXT. En las conferencias sobre redes, hipertexto y 
software, Robert y yo explicábamos que para que el Web creciese, ne- 
cesitábamos clientes para los PC, Macintosh y Unix. En el CERN, me 
presionaban para que hiciera un cliente para el sistema X-Windows 
usado por la mayoría de los aparatos Unix, pero no tenía recursos. Es- 
tábamos tan ocupados tratando de hacer funcionar el Web que no ha- 
bía forma de que nosotros mismos pudiésemos desarrollar navegado- 
res, así que sugerimos enérgicamente a quien nos quiso oír que la 
creación de navegadores sería un proyecto muy útil para los estudian- 
tes de software en las universidades. 

Nuestra estrategia tuvo resultado cuando Robert visitó la Univer- 
sidad de Tecnología de Helsinki. Varios estudiantes estaban decididos 
a hacer un navegador web para su proyecto conjunto de doctorado. 
Como el departamento era “OTH”, decidieron llamar al navegador 
Erwise (OTH + Erwise = “Otherwise”) !. 

Cuando se terminó el proyecto, en abril de 1992, Erwise resultaba 
bastante avanzado. Estaba escrito para ser utilizado en un aparato 
Unix que utilizara X-Windows. Fui a Finlandia a animar a los estu- 


í Otherwise significa “de otro modo”, “de lo contrario”. 
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diantes a seguir con el proyecto después de que se hubieran licencia- 
do, y a extender el navegador a un editor, pero ellos tenían un entu- 
siasmo por el Web francamente pequeño; ya habían decidido que 
cuando se graduasen, iban a seguir con lo que consideraban proyectos 
más emocionantes o lucrativos de software. Nadie en el instituto quiso 
tampoco recoger la idea del proyecto. Ciertamente yo no podía conti- 
nuarlo; ¡toda la codificación estaba documentada en finés! 

Otro navegador de señalar-y-cliquear apareció casi al mismo tiem- 
po, sin embargo. Pei Wei, un estudiante muy imaginativo de la Uni- 
versidad de Berkeley, había creado un lenguaje de programación in- 
terpretado llamado Viola para ordenadores Unix. Había estado 
trabajando mucho tiempo en él y el lenguaje tenía una funcionalidad 
potente para mostrar cosas en la pantalla. Para demostrar la potencia 
del Viola, Pei decidió escribir un navegador web, Viola WWW. Era 
bastante avanzado: podía mostrar HTML con gráficos, hacer anima- 
ciones y descargar pequeñas aplicaciones insertadas (conocidas más 
tarde como applets [subprogramas]) sacados de Internet. Estaba ade- 
lantado a su tiempo, y aunque se hizo poco caso a Pei, Viola WWW es- 
tableció un temprano estándar, y también tenía muchos de los atribu- 
tos que aparecerían varios años más tarde en el popular programa 
HotJava, que tomaría por asalto la comunidad del Web. 

Pei distribuyó una versión de prueba de su navegador en el Web 
en mayo de 1992. La única característica incómoda era que era difícil 
para el usuario instalarlo en su ordenador. Primero había que instalar 
Viola, y luego Viola WWW como aplicación de Viola. Esto llevaba 
tiempo y era complicado. Pero finalmente, la gente que trabajaba con 
aparatos Unix —y había muchos en empresas y universidades de todo 
el mundo— podían acceder al Web. 

Aunque los navegadores estaban empezando a extenderse, nadie 

que trabajase con ellos trataba de incluir funciones. Parecía haber la 
idea de que crear un navegador compensaba, ya que hacía que la in- 
formación de todo el mundo estuviese disponible para cualquiera que 
lo usase. Poner tanto esfuerzo en la parte colaboradora del Web no 
parecía prometer aquella multiplicación geométrica. Tan pronto 
como los creadores conseguían que su cliente funcionase como un na- 
vegador y lo lanzaban al mundo, pocos se preocupaban por seguir de- 
sarrollándolo como editor. 
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Sin un editor de hipertexto, la gente no tenía las herramientas para 
usar de verdad el Web como un medio de colaboración íntima. Los 
navegadores permitían encontrar y compartir información, pero no 
podían funcionar conjuntamente en colaboración. Supuse que parte 
de la razón era que la colaboración requería un cambio social en el 
modo en que la gente trabajaba. Y parte de ello era que los editores 
eran mucho más difíciles de escribir. 

Por estas razones el Web, que yo había diseñado para que fuese un 
medio de toda clase de informaciones, desde lo muy local hasta lo 
muy global, creció decididamente en dirección de lo muy global, y 
también como medio de publicación, pero menos como medio de co- 
laboración. 

Había varias bolsas de uso interno inter:sivo. El CERN era una de 
ellas. Dentro de Digital Equipment había cien servidores del Web al 
principio que no eran accesibles desde el exterior. A estos servidores 
internos no se les había dado una publicidad adecuada, así que los pe- 
riodistas no podían utilizarlos. Años más tarde, los medios “descubri- 
rían” de repente la “subida” de estas redes web internas e inventarían 
el término intranet, lo que significaba que se usaban ampliamente 
para comunicaciones internas en empresas. Me pareció en cierto 
modo irónico, ya que había estado sucediendo durante todo el tiem- 
po, y fue el principio que hizo necesario el Web en primer lugar. 

Con Erwise y Viola a bordo, Robert se puso a diseñar un navega- 
dor para su ordenador favorito, el Macintosh. Robert era un purista, 
no un pragmático como yo. En el Mac, encontró la realización de sus 
más altos ideales acerca de cómo deberían ser los ordenadores: sen- 
cillos y de uso intuitivo. Pero el idealismo de Robert era a veces un 
obstáculo cuando se trataba de conseguir que un proyecto se realiza- 
ra, Como ya he dicho, yo había encontrado un poco de espacio extra 
en el código del editor de texto en el aparato NeX'T, donde podía al- | 
macenar la información URI que definía cada vínculo de hipertexto. 
Esto resultó ser esencial para poder hacer el servidor web de un modo 
simple. 

Los diseñadores del editor de texto Macintosh tenían una estruc- 
tura similar, pero sin el espacio extra. Sin embargo, habían dejado 
aparte treinta y dos bits para almacenar el color del texto, y usaban 
sólo veinticuatro. Sugerí que usásemos los ocho bits libres y robamos 
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unos cuantos más a los que se usaban para el color, que no provoca- 
rían cambio alguno en los colores que los usuarios iban a ver. 

Robert estaba horrorizado, horrorizado ante la idea de usar un 
campo destinado al color para otra cosa, horrorizado por remeter los 
datos de hipertexto en las grietas de los datos de color. El programa 
quedó en espera durante un tiempo, mientras-yo intentaba convencer 
a Robert de que tomar ese camino, ciertamente poco elegante pero 
sencillo, le permitiría seguir con el resto del proyecto y conseguir de 
verdad que el navegador web funcionase. Al final lo aceptó, pero tuvo 
poco tiempo para continuar con el programa. Más tarde, un verano, 
Nicola Pellow volvió durante unas semanas y lo retomó, y en cierto 
momento acabó funcionando. Lo llamamos Samba. 

Cada equipo disfruta de una diversidad de estilos, y mi colabora- 
ción con Robert no fue una excepción. La insistencia de Robert en la 
calidad de la presentación nos hizo hacer muchos informes, demostra- 
ciones y presentaciones. Mientras tanto, Robert rebuscaba incansable 
más recursos. Acabó trayéndose a los estudiantes Henrik Frystyk 
Nielsen y Ari Luotonen para que se uniesen al equipo. Henrik, un afa- 
ble danés rubio, se responsabilizó de la biblioteca codificada y el na- 
vegador modo-línea. Ari, un bravo finlandés moreno, se puso con el 
servidor. Los dos se metieron a fondo y emplearon más tiempo y ener- 
gía en los productos de lo que hubiera podido hacer yo, volviéndolos 
en algunos casos del revés para reescribirlos mejor. Este esfuerzo apo- 
yó a un número creciente de sitios web, y “productivizó” nuestro tra- 
bajo, para que los usuarios lo encontrasen fácil de instalar y utilizar. 


A medida que iban apareciendo los navegadores, lo mismo ocurrió 
con los nuevos servidores, con una frecuencia cada vez mayor. Ocasio- 
nalmente, un nuevo servidor demostraría a la comunidad lo que pue- 
de hacerse de un modo completamente distinto, e introduciría energía 
fresca en tan joven terreno. Uno que me impresionó fue un servidor 
de información acerca de Roma durante el Renacimiento. El Vaticano 
había prestado una exposición (real) a la Biblioteca del Congreso de 
América. Parte del material que había en ella fue fotografiado, esca- 
neado en un ordenador, y estaba disponible en forma de archivo de 
imágenes en un servidor FTP de Internet. Entonces, en Europa, Frans 
van Hoesl, que conocía el Web, creó un mundo de hipertexto de este 
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material en un sitio web. El sitio adquirió la forma de un museo vir- 
tual; un navegador escogía un ala que visitar, luego un pasillo y luego 
una sala. 

En mi primera visita, caminé hasta una sala de música. Había va- 
rías pinturas minúsculas, y debajo de una estaba la explicación de los 
acontecimientos que hicieron al compositor Carpentras presentar un 
manuscrito decorado de sus Lamentaciones de Jeremías al papa Cle- 
mente VII. Cliqueé y me alegré de tener una pantalla de veíntiuna pul- 
gadas: de pronto se llenó de una partitura hermosamente iluminada, 
que podía contemplar seguramente con más comodidad y con más 
detalle que si hubiera ido a la exposición original en la Biblioteca del 
Congreso. Esta utilización del Web para llevar importantes recursos a 
gente lejana, y el idioma de navegación usado para hacer el museo vir- 
tual enraizaron y fueron la inspiración de muchos excelentes sitios 
web. También era un buen ejemplo de cómo una combinación de es- 
fuerzos en todo el mundo podía conducir a cosas fantásticas. 

Otro clásico de esa época fue un servidor de Steve Putz, de Xerox 
PARC. Tenía una base de datos de información geográfica que gene- 
raba sobre la marcha un mapa virtual en respuesta a los clics de un 
usuario para hacer zoom y ver panorámicamente. Resultaría ser el pri- 
mero de los muchos servidores de mapas web que estaban por llegar. 

Al ver esos sitios, grupos de científicos y gobernantes que tenían la 
obligación de hacer que sus datos estuviesen disponibles, se estaban 
dando cuenta de que sería más fácil meter la información en el Web 
que contestar repetidas preguntas sobre lo mismo. Antes, cuando otro 
científico pedía sus datos, tenían que escribir un programa (custom) 
para traducir su información a un formato que la persona pudiera 
usar, Ahora podían limitarse a meterlo en el Web y decir a quien lo 
quisiera que consiguiera un navegador. Y la gente lo hacía. La acepta- 
ción del Web iba en aumento. Las excusas para no tener un navegador 
eran cada vez más débiles. El trineo estaba empezando a deslizarse. 


A medida que se acercaba junio de 1992, yo cada vez sentía con más 
fuerza la necesidad de un año sabático. David Williams, director de 
mi departamento en el CERN, lo había previsto y estaba preparado, 
con una oferta que no pude rechazar. Me explicó que podía marchar- 
me durante un año y disponer de mi trabajo cuando volviera. Sin em- 
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bargo, durante ese año yo perdería mi sueldo y ventajas en el CERN, 
que eran muy buenos, y tendría que pagar todos mis gastos de viaje. 
Como alternativa, David dijo que podría irme de viaje de negocios du- 
rante tres meses y me pagaría una cantidad diaria por este “extenso 
viaje de obligaciones”, además de mi sueldo y ventajas de entonces. 
Como es natural, escogí la segunda opción. M+ esposa y yo planeamos 
tres meses de trabajo y vacaciones combinados. Visitaría el Laborato- 
rio de Ciencias Informáticas (LCS) del MIT en Cambridge, Massachu- 
setts, y también asistiría a la reunión del IETF en la cercana Boston. 
Luego nos iríamos de vacaciones a New Hampshire y acabaríamos en 
la zona de San Francisco, donde visitaría Xerox PARC. 

El verano resultó ser una gran oportunidad para mí para hacerme 
ala idea del estado de la penetración y aceptación del Web en Estados 
Unidos. 

La gente del LCS había instalado Viola, y. el MIT estaba ya muy 
metido en el Web. El nombre 1vwW4w.m:t.edu lo había adoptado muy 
pronto un club de estudiantes de informática, así que “web.mit.edu” 
se convertiría en el nombre del principal servidor del MIT, y lo segui- 
ría siendo. En el LCS describí las ideas que había detrás del Web a un 
selecto grupo de individuos en el auditorio de la quinta planta. Algu- 
nos de los investigadores y administradores se preguntaban por qué 
estaba yo allí. Yo estaba tratando de ver cómo esa creación, que era 
realmente un asunto de ingeniería, podía encajar desde el punto de 
vista de la comunidad investigadora, lo que el Web podía aprender 
de los investigadores en ese campo, y por qué eso no había ocurrido 
antes. 

En la reunión del IET'F mantuve una reunión de “pájaros del mis- 
mo plumaje” para investigar la formación de un grupo de trabajo para 
normalizar las especificaciones URI, según sugirió Joyce Reynolds. 
Nos reunimos en una pequeña sala del hotel Hyatt. Presenté la idea 
como ¿dentificador universal de documentos —el nombre que le di ini- 
cialmente— y dije que estaba interesado en que fuese adoptado como 
estándar de Internet. Las cosas fueron regular. La discusión abierta 
fue estupenda. Yo me sentía en minoría. Había otra minoría que me 
consideraba un intruso recién llegado. 

Aunque yo sólo estaba pidiendo que se normalizara una parte del 
Web, hubo una fuerte reacción en contra dela “arrogancia” de llamar 
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a algo un identificador universal de documentos. ¿Cómo podía ser tan 
presuntuoso como para definir mi creación como “universal”? Si que- 
ría que las direcciones UDI se normalizaran, el nombre “identificado- 
res uniformes de documentos” sería suficiente. Sentí una fuerza inme- 
diata y poderosa entre la gente que se encontraba allí. Estaban 
tratando de confinar al Web en una cajita: nada puede ser universal. 
Otros contemplaban el IETF como un lugar en el que se podía crear 
algo universal, pero ese algo no iba a ser el Web. Aquellas tensiones 
continuaron durante la reunión del TETF y en reuniones posteriores. 
Algunas personas querían integrar al Web con otros sistemas de infor- 
mación, cuando el Web estaba definido precisamente para ser la inte- 
gración de todos los sistemas de información. 

Traté de explicar en la sesión lo importante que era que el Web 
fuese considerado universal, pero decidí no gastar saliva. Pensé: 
“¿Qué importancia tiene el nombre?”. Si continuaba con el proceso 
de normalización y esa gente accedía, y lo único que tenía que hacer 
era llamarlo uniforme, mientras consiguiese la especificación adecua- 
da, por mí, estupendo. Estada deseando llegar a un compromiso, para 
poder empezar con los detalles técnicos. Así que universal se convirtió 
en uniforme, y documento se convirtió en recurso. 

Finalmente resultó que había sido importante fijar el nombre, 
porque detrás del nombre estaban los puntales filosóficos fundamen- 
tales de lo que estaba tratando de ser el Web. Por fin el grupo decidió 
formar un grupo de trabajo identificador de recursos uniforme. Sin 
embargo, decidieron que identificador no era una buena etiqueta para 
lo que usaba el Web. Querían subrayar el hecho de que la gente podía 
cambiar los URIs cuando trasladaban documentos, así que debía tra- 
tarse de una especie de dirección transitiva. Se escogió localizador, 
como una marca de aviso sobre la tecnología. Yo quería conservar 
¿dentificador, porque aunque en la práctica muchos URIs cambiaban, 
el objeto era que fuesen lo más permanentes posibles. Discutimos, 
pero en el IETF el identificador universal de recursos se convirtió en 
URL, localizador uniforme de recursos. En años posteriores la comuni- 
dad del TETEF usaría las siglas URL, permitiendo el uso del término 
URI para lo que era un URL, o bien algo más persistente. Yo uso el 
término general URI para enfatizar la importancia de la universalidad, 
y de la persistencia de la información. 
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El progreso del grupo de trabajo URI era lento, en parte debido al 
número de infinitas ratoneras filosóficas en las que desaparecían las 
conversaciones técnicas. Cuando años más tarde el grupo de trabajo 
URI tuvo que reunirse doce veces y aún así no consiguió ponerse de 
acuerdo en un documento de nueve páginas, John Klensin, el por en- 
tonces director del Área de Aplicaciones del TETF estuvo a punto de 
disolverlo furioso. Á veces se discutía una filosofía interna que desde 
mi punto de vista, era algo que no se podía discutir. A veces había una 
decisión básicamente arbitraria (como qué caracteres de puntuación 
usar) que yo ya había tomado, y cambiarla significaría nada menos que 
millones de navegadores y vínculos web ya existentes tendrían que 
cambiarse. Tras meses de discusiones incontroladas en el TE TE, pa- 
recía que las alternativas eran, o hacerse con el Web entero, o nada. Al 
final escribí una especificación acerca de cómo se usaban los URlIs en 
el Web, y la distribuí a la comunidad del TETF como un “Envío para 
comentar 1630” informativo. Aunque apresurado y con unos cuantos 
errores, sería un escalón hacia futuros progresos. Todo el asunto ha- 
bría ido más fácilmente también si yo hubiera sido más insistente acer- 
ca de los puntos sobre los que estaba preparado para negociar y sobre 
los que no. 

Mi estancia en el LCS fue más positiva, y lo mismo ocurrió cuando 
estuve en Xerox PARC, Como estaban muy preocupados por la segu- 
ridad, en PARC tenían muchos servidores experimentales disponibles 
internamente, protegidos detrás de una pantalla incorporada dentro 
de su sistema para evitar a los de fuera acceder electrónicamente de 
manera ilegal. Había una manera especial de conectarse desde dentro 
afuera. No usaban Viola porque tenía que ser compilado con un códi- 
go especial para hacer esa conexión, así que lo primero que hice al lle- 
gar fue eso precisamente, 

También visité otros importantes actores del mundo del Web 
mientras estaba en la zona de San Francisco. Cuando iba a PARC, pa- 
saba en bicicleta todos los días junto a SLAC. Me detuve a ver a Paul 
Kunz y a Louise Addis, promotores e instaladores pioneros del Web, 
También me reuní con Pei Wei, que seguía en la Universidad de Ber- 
keley. Aunque Viola estaba llamando la atención, la dificultad de ins- 
talarlo limitaba su atractivo. Me encontré con Pei en un café en las 
afueras de San Francisco para tratar de convencerle de que hiciera 
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más fácil la instalación, y dar capacidad de editar a su navegador tam- 
bién; ése seguía siendo mi ideal. Pero el interés de Pei seguía estando 
en Viola como lenguaje de ordenador; veía el Web como sólo una apli- 
cación más. Traté de animarle pero no insistí. Después de todo, Viola 
estaba ampliando enormemente el alcance del Web. Parte de mis ra- 
zones para verle eran sencillamente decirle en persona: “Gracias, bien 
hecho”. 

La conducta modesta de Pei y su falta de arrogancia acerca de sus 
ideas eran notables, teniendo en cuenta que su producto era estupen- 
do. Cuando le felicité y le dije que si se desarrollaba más, Viola se con- 
vertiría en el buque insignia de los navegadores del Web, Pei sonrió, 
pero quería reservar su programa como herramienta propia de inves- 
tigación. Iba a unirse al grupo Digital Media en O'Reilly Associates en 
Sebastopol, California, empresa dirigida por Dale Dougherty, uno de 
los primeros entusiastas del Web, que estaba creando varios produc- 
tos de Internet. Él usaba Viola para demostrar el aspecto que podían 
tener diferentes productos en línea usando diferentes estilos. 

Como el proceso de instalación era algo demasiado complejo, Vio- 
la estaba destinado a ser eclipsado por otros futuros navegadores. 
Ciertamente ya había competencia entre los navegadores web. Mien- 
tras Erwise y Viola WWW competían como navegadores para el siste- 
ma X-Windows en Unix, Tony Johnson, del SLAC, entró en combate. 
Era un físico que había desarrollado otro navegador para X llamado 
Midas, en parte porque le gustaba ver un programa bien escrito, y en 
parte porque en su proyecto quería usar el Web para difundir su in- 
formación, y quería un navegador que pudiera controlar. Usaba un 
bonito modelo conceptual, la programación era muy limpia y le per- 
mitía, por ejemplo, importar imágenes de un modo muy flexible. 

Vi a Tony en su oficina del SLAC. Aunque hacía presentaciones 
por el SLAC acerca del Midas, y lo usaba él mismo, estaba tan reticen- 
te como Pei o el grupo Erwise a unirse a mis esfuerzos en el CERN, in- 
cluso aunque probablemente eso le proporcionaría recursos extras. 
Tony era y es en primer lugar un físico, y no le gustaba la idea de pro- 
porcionar el Midas a un grupo que fuera más amplio que el de sus co- 
legas. 

El mes que estaba pasando en California se estaba acabando y 
pronto mi familia y yo tendríamos que volver a Ginebra. Pero no po- 
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día volver sin hacer una parada más, que pensaba que iba a ser la me- 
jor del verano. Ted Nelson, que había concebido Xanadu hacía veinti- 
cinco años, vivía cerca, y yo tenía que conocerle. 

- Diversas personas habían abordado diferentes aspectos de las im- 
plicaciones sociales del hipertexto. Para Ted, el hipertexto era lo 
opuesto del copyright. La idea entera del Xanadu se regía por la idea 
de que cualquiera debiera poder publicar información, y si alguien 
quería usar esa información, el creador debería ser automáticamente 
recompensado. Una de las razones por las que Xanadu nunca despegó 
fue la insistencia de Ted en que hubiera un mecanismo valorador, y la 
dificultad de crear uno que fuese válido en todo el mundo. En teoría 
esto debería ser posible en el Web con ciertas extensiones, y un siste- 
ma de “micropagos” —pequeños débitos contra la cuenta bancaria de 
una persona— permitiría los pagos automáticos en cantidades muy 
pequeñas. Á mí no me gustaba mucho la idea de tener sólo un modelo 
de negocio para pagar por información. Pero estaba deseando cono- 
cer a Ted. 

Habíamos mantenido correspondencia sólo unas cuantas veces 
por e-mail, y la relación en ciernes que teníamos era bastante rara, 
para mí por lo menos, porque durante largo tiempo, debí dinero a 
Ted. Supe de Ted por primera vez en 1988, leyendo sobre hipertex- 
to. Su principal libro por entonces era Lzterary Machines publicado 
en Mindful Press, que Ted dirigía como editorial de un solo hom- 
bre. Un poco más adelante le encargué el libro con un cheque en 
dólares U.S. de mi cuenta en Suiza. Los cheques suizos son muy in- 
ternacionales, y tienen un espacio para la cantidad y un espacio 
para el tipo de divisa, pero no me di cuenta de que los bancos ame- 
ricanos no los aceptaban. Él envió el libro, pero yo no conseguí pa- 
garle, porque él no admitía tarjetas de crédito y yo no tenía cheques 
americanos. 

Así se había quedado la cosa. Le llamé desde PARC y descubrí 
que vivía en una casa-barco en Sausalito, al otro lado del Golden 
Gate, cruzando desde San Francisco. Era el lugar más cercano a don- 
de estaban ocurriendo las cosas y lo bastante excéntrico como para 
que él viviera. Autodesk se había hecho cargo de Xanadu, y Ted tenía 
un puesto honorífico en la compañía. Pero el día en que quedé para 
comer con él fue un día triste. Aquella misma mañana, Autodesk ha- 
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bía decidido que Xanadu era un proyecto poco práctico después de 
todo. Lo abandonaban, dejando el proyecto sin hogar. 

De todos modos, Ted me invitó a una comida india, y luego fui- 
mos a su oficina, que parecía ser un ático en un edificio piramidal en el 
litoral de Sausalito. Estaba lleno de ejemplares de sus libros. Yo le di el 
dinero que le debía y él rápidamente me dío otro líbro, autografiado. 
Hablamos de toda clase de cosas, pero no mucho de Autodesk, 

Después de comer, Ted me acompañó hasta mi coche en el aparca- 
miento. Yo saqué mi cámara de 35 mm del maletero para inmortalizar 
el momento. Le pregunté a Ted, con cierto embarazo, si no le impor- 
taba posar para mi libro de recuerdos. Él contestó: “Desde luego, sin 
duda. Lo entiendo muy bien”. Entonces sacó de su mochila una vi- 
deocámara y rodó unas imágenes de mí. Pero antes de hacerlo, sostu- 
vo la cámara en el extremo del brazo, se enfocó y se rodó a sí mismo 
explicando que iba a rodar a Tim Berners-Lee, y lo significativo que 
era. Ted me explicó que su objetivo era llevar una vida lo más intere- 
sante posible, y grabar todo lo posible de la vida de otras personas. 
Con este fín había reunido un enorme número de cintas de vídeo, que 
estaban ordenadas mediante una imagen de su propia cabeza; de ese 
modo, cuando las miraba, cada vez que veía su cabeza, podía escuchar 
una descripción del vídeo que venía a continuación. 


El verano de 1992 fue para mí una época interesantísima. El Web se 
estaba viendo y usando en muchos lugares, y había más gente desatro- 
llando navegadores para él. Repasé los registros que mostraban el trá- 
fico que el primer servidor web, info.cern.ch, había recibido durante 
los últimos doce meses. La curva que mostraba el número de accesos 
diarios era un exponencial tremendo, y se doblaba cada tres o cuatro 
meses. Después de un año, la carga había crecido en un factor de diez. 


6. NAVEGANDO 


En enero de 1993 el número de servidores conocidos estaba creciendo 
cada vez más deprisa, hasta llegar a casi cincuenta. Los navegadores 
Erwise, Viola y Midas estaban disponibles en general para su uso en el 
sistema X-Windows. Samba estaba funcionando, aunque no comple- 
tamente, para el Mac. Pero para mí estaba claro que había una compe- 
titividad creciente entre navegadores, aunque fuese a pequeña escala. 
Muchas de las personas que desarrollaban navegadores eran estudian- 
tes, y tenían tendencia a añadir características a su versión antes de 
que alguien más añadiese características similares. Mantenían discu- 
siones abiertas acerca de estas cosas en la lista de correo www-talk, 
conservando los procesos sociales abiertos que caracterizaron el desa- 
rrollo del software de Internet. 

Uno de los pocos industriales comerciales que se unieron a la ca- 
rrera fue Dave Raggett, de Hewlett-Packard en Bristol, Inglaterra. 
Creó un navegador llamado Arena. HP tenía el acuerdo de que un 
empleado podía hacer trabajos útiles, relacionados con la empresa 
pero no oficiales durante el 10% de su tiempo laboral. Dave pasó su 
“10% del tiempo” más un montón de tardes y fines de semana con el 
Arena. Estaba convencido de que las páginas web de hipertexto po- 
dían ser mucho más emocionantes como páginas de revista en lugar 
de páginas de libro de texto, y que el HTML podía ser utilizado para 
colocar no sólo texto en una página sino imágenes, tablas y otras co- 
sas. Usó Arena para demostrar todas esas cosas, y para experimentar 
con diferentes formas de leer e interpretar páginas HTML tanto váli- 
das como incorrectamente escritas. 

Mientras tanto, la Universidad de Kansas había escrito, indepen- 
dientemente del Web, un navegador de hipertexto, Lynx, que funcio- 
naba con terminales de 24 líneas de 80 caracteres cada una. Más sofis- 
ticado que nuestro navegador modo-línea, Lynx era un navegador 
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“modo pantalla”, que permitía ir hacia atrás y hacia delante en un do- 
cumento. Había sido diseñado, al igual que Gopher, como un sistema 
de información para el interior del campus, y el equipo bromeaba di- 
ciendo que los linces (Lynx) se comían a las ardillas (Gopher). Lou 
Montulli, un estudiante, lo adaptó al Web y lanzó un navegador web, 
Lynx 2.0, en marzo de 199. 

Desarrollar navegadores se había ouveráda en un buen siste- 
ma para que estudiantes e ingenieros mostrasen sus habilidades 
programadoras. Dave Thompson, un directivo del National Center 
for Supercomputing Applications [Centro Nacional de Aplicacio- 
nes Superinformáticas] (NCSA) en la Universidad de Illinois, en 
Urbana-Campaign, necesitaba estudiantes para intentarlo. Descar- 
gó Viola, lo puso a funcionar e hizo una demostración de su uso con 
el servidor del CERN al resto del Grupo de Diseño de Software de 
NCSA. 

Marc Andreessen, estudiante, y Eric Bina, miembro del personal, 
decidieron crear un navegador para X. Eric era en cierto modo como 
Pei Wei; estaba programando en silencio el código HTML y hacía 
funcionar el asunto. Marc mantenía una presencia casi constante en 
los grupos de noticias que hablaban del Web, escuchando las peticio- . 
nes que hacía la gente y lo que haría que los navegadores fuesen más 
fáciles de usar. Programaría aquéllos en el navegador naciente y no de- 
jaba de publicar nuevas ediciones para que otros pudiesen probarlas. 
Escuchaba atentamente las críticas, casi como si fuese el encargado de 
las “relaciones con el cliente”. Alimentado, según se decía, por gran- 
des cantidades de café exprés, localizaba virus y añadía pequeñas ca- 
racterísticas a últimas horas de la noche como reacción a los estímulos 
de los usuarios. 

Esto era un contraste total con cualquiera de los demás estudian- 
tes. Marc no estaba interesado sólo en hacer que el programa funcio- 
nase, sino en que su navegador fuese utilizado por tanta gente como 
fuese posible. Esto era, naturalmente, lo que necesitaba el Web. 

El navegador resultante se llamó Mosaic. En febrero de 1993 el 
NCSA hizo que la primera versión estuviera disponible en el Web. Yo 
la probé en el CERN. Era fácil de descargar e instalar, y requería muy 
poco aprendizaje antes de que pudiera tener acceso gráfico con ratón 
al Web. A causa de estas características, Mosaic se adoptó mucho más 
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rápidamente que otros navegadores. Mosaic era un producto mucho 
más serio. 

Me preocupaba en cierto modo que el NCSA estuviese hablando 
siempre de Mosaic, a menudo sin mencionar apenas el World Wide 
Web. Quizás no fuese más que puro entusiasmo. * 

Tenía previsto hacer una presentación al Fermi National Accelera- 
tor Laboratory [Laboratorio de Acelerador Nacional Fermi] (Fermi- 
lab) en Chicago en marzo, que habían hecho un servidor igual que el 
SLAC. Decidí que visitaría también el NCSA, ya que no estaba más 
que a unas horas de coche. 

Cuando estaba en Chicago, conocí a Tom Bruce, un directivo 
convertido en administrador de sistemas convertido en programa- 
dor, que recientemente había cofundado el Instituto de Información 
Legal en la Universidad de Cornell, para proporcionar información 
legal y hallazgos legales en línea. Él pensaba que el Web era exacta- 
mente lo que necesitaba el instituto para distribuir su información 
entre la comunidad legal. Se había dado cuenta de que la mayoría 
de abogados usaban PCs IBM o compatibles, que funcionaban con 
el sistema operativo Windows, y necesitarían un navegador. Así que 
había escrito Cello, un navegador de señalar-y-cliquear para Win- 
dows. Fue un lanzamiento de la versión alfa (una primera versión 
inicial de prueba) en marzo, y había venido a Chicago a dar una 
charla a la comunidad legal. Por primera vez la gente podía ver el 
Web en su gloria multicolor y multifuente en la plataforma informá- 
tica más extendida del mundo. 

Encontré a “Tom en un auditorio justo después de que hubiese aca- 
bado su charla. Su ordenador portátil seguía encendido, con la panta- 
lla proyectada sobre una gran pantalla de cine al fondo de la sala. Allí 
me hizo una demostración del Cello, los dos sentados solos en aquella 
gran sala mirando una gran imagen del Web. Tenía múltiples fuentes, 
colores y estilos seleccionables por el usuario. Utilizaba una línea de 
puntos alrededor del texto indicando un vínculo de hipertexto, lo que 
se ajustaba a las convenciones de Windows. Descubrí, hablando con 
él más tarde, que había trabajado profesionalmente con equipos de 
iluminación y audiovisuales en el teatro. Yo había hecho lo mismo 
como aficionado. Compartíamos el entusiasmo de la vocación e hici- 
mos buenas migas. 
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Pedí a Tom, y a Ruth Pordes, mi anfitriona en Fermilab y fuente 
de honrada sabiduría, que viniesen conmigo a conocer a Marc Andre- 
essen y a los chicos del NCSA, Ruth nos llevó a través de aparente- 
mente interminables campos de maíz. Para alguien que había vivido 
en Ginebra, me llamó la atención la notable falta de montañas. 

Los tres encontramos el Grupo de Desarrollo de Software, aun- 
que no estaba en los imponentes edificios de ladrillo y vidrio verde 
que albergaban la mayor parte del NCSA, sino en un anexo del edifi- 
cio de química petrolífera. Conocimos a Eric, a Marc y al líder del gru- 
po, Joseph Hardin, en una sala de juntas del sótano. 

Todas mis primeras reuniones con creadores de navegadores ha- 
bían sido reuniones de mentes, con coincidencia en el entusiasmo. 
Pero en esta reunión había una extraña tensión. Durante los días ante- 
riores a mi viaje a Chicago, estaba empezando a tener claro que la gen- 
te del NCSA estaban tratando de mostrarse a sí mismos como el cen- 
tro del desarrollo del Web, e intentaban llamar al Web Mosaic. En el 
NCSA, las cosas no estaba “en la Red”, estaban “en Mosaic”. Marc 
pareció darse cuenta de lo que eso me incomodaba. 

Sin embargo, no lo utilicé como tema de conversación y me dispu- 
se a hablar de convertir el navegador Mosaic en un editor también. 
Marc y Eric explicaron que habían intentado esa posibilidad y que ha- 
bían concluido que era totalmente imposible. No se podía hacer. Esto 
era nuevo para mí, ya que yo ya lo había hecho con el World Wide 
Web en el NeXT, aunque había que admitir que con una versión más 
simple de HTML. 

Aún así, me sorprendió este desdén casi universal por crear un 
editor. Quizás fuese demasiado impresionante. O quizás no era más 
que una cuestión del tiempo del que disponían los que tenían que de- 
satrollar el proyecto. Pero también era cierto que muchos estaban más 
interesados en meter características de fantasía en los navegadores - 
—multimedia, diversos colores y fuentes—, que llevaban mucho me- 
nos trabajo y creaban mucha excitación entre los usuarios. Y Marc, 
más que nadie, parecía interesado en responder a los deseos de los 
usuarios. 

También advertí otras tensiones. Había una enorme diferencia de 
estilo entre los tres hombres, y cada uno de ellos parecía pensar por 
su cuenta, en lugar de como equipo. Eric, el empleado, era callado. 
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Marc, el estudiante, daba la impresión de considerar esta reunión 
como una partida de póker. Hardin era muy académico, el típico pro- 
fesor con chaqueta de tweed. Le interesaban las implicaciones sociales 
del Web además de la tecnología, y los estudios sociológicos acerca del 
Web. Para él, Mosaic era una secuela de un proyecto que ya tenía el 
NCSA, un sistema multimedia de hipertexto llamado Collage. 

Para mayor consternación todavía por mi parte, el departamento 
de relaciones públicas del NCSA también estaba promocionando Mo- 
saic. No pasó mucho tiempo antes de que el New York Times sacase 
un artículo en el que salían Hardin y Larry Smarr, el director del 
NCSA (¡Marc y Eric, no!) sentados uno al lado del otro junto a termi- 
nales en las que estaba Mosaic funcionando. Una vez más, el centro de 
atención era Mosaic, como si fuera el Web. No se hacía apenas men- 
ción a otros navegadores, ni siquiera a los esfuerzos del resto del mun- 
do para crear servidores. Los medios de comunicación, que no se to- 
maban la molestia de investigar más a fondo, empezaban a mostrar 
Mosaic como si fuera un equivalente del Web. 

Volví al CERN incómodo con los murmullos decididamente auto- 
ritarios que estaban detrás de la promoción de Mosaic por parte del 
NCSA. El NCSA puso en marcha rápidamente otros proyectos para 
conseguir que Mosaic funcionase en los PCs con Windows, y en los 
Macintosh. 


El surgimiento de diferentes navegadores me hizo pensar una vez 
más acerca de la normalización. La ruta IETF no parecía estar funcio- 
nando. Pensé que quizás un modelo diferente funcionaría. Me entu- 
siasmé más con la idea durante un seminario en la Universidad de 
Newcastle en mi nativa Inglaterra, organizado por International 
Computers Ltd. El tiempo primaveral era húmedo y oscuro. Nos lle- 
varon en autobús una lluviosa tarde desde el seminario a cenar. Á la 
vuelta, me senté junto a David Gifford, que resultó ser profesor en el 
LCS del MIT. Le dije que estaba pensando en poner en marcha algún 
tipo de corporación para vigilar la evolución del Web. Me pregunta- 
ba si esa clase de estructura podría funcionar, y dónde debería tener 
su base. Él dijo que debería hablar con Michael Dertouzos acerca de 
ello. Me explicó que Michael era el director del LCS y que pensaba 
que Michael estaría interesado en hacer algo. Expresé una feliz sor- 
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presa, anoté mldOhg.lcs.mit.edu, y rápidamente le envié un e-mail 
nada más volver al CERN. 

Estaba más motivado aún por un fenómeno de Internet que esta- 
ba teniendo lugar recientemente. El sistema de información gopher 
de la Universidad de Minnesota se había puesto en marcha al mismo 
tiempo que el Web. Fue creado originalmente como un sistema de 
ayuda en línea para el departamento de informática de la Universidad 
y se extendió para convertirse en un sistema de información del cam- 
pus que también permitía a la gente compartir documentos en Inter- 
net. En lugar de usar hipertexto y vínculos, presentaba menús a los 
usuarios, llevándoles luego hasta documentos normalmente de texto 
sólo. Yo había descubierto que algunas personas, cuando veían el 
Web, pensaban que el hipertexto era confuso, o les preocupaba que de 
alguna manera se pudieran perder en el hiperespacio cuando seguían 
un vínculo. Naturalmente, esto podía suceder también en el gopheres- 
pacio, pero los usuarios de ordenadores estaban familiarizados con los 
menús, así que el programa no les parecía extraño. 

Fue por esa época, la primavera de 1993, cuando la Universidad 
de Minnesota decidió pedir una tasa de licencia a cierta clase de usua- 
rios que querían usar el gopher. Como el software del gopher se estaba 
expandiendo tanto, la universidad iba a cobrar una tasa anual. El na- 
vegador, y el acto de navegar, serían gratuitos, y el software del servi- 
dor seguiría siendo gratuito para instituciones educativas y no lucrati- 
vas. Pero cualquier otro usuario, sobre todo las empresas, tendría que 
pagar para usar el software del servidor gopher. 

Esto era un acto de traición en la comunidad académica y la co- 
munidad de Internet. Incluso aunque la universidad nunca cobrara 
un penique, el hecho de que la escuela anunciara que se reservaba el 
derecho a cobrar a la gente por el uso de los protocolos gopher signifi- 
caba que había cruzado la línea. Usar la tecnología era demasiado 
arriesgado. 

La industria abandonó el gopher como una patata caliente. Los 
promotores sabían que no podían hacer nada que se pudiera relacio- 
nar con el protocolo gopher sin preguntar antes a sus abogados para 
negociar los derechos. Incluso si una compañía escribía su propio 
cliente o servidor gopher, la universidad podía demandarla más tarde 
por infringir algún derecho de propiedad intelectual. Se consideraba 
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peligroso incluso que un ingeniero leyera la especificación o viera pat- 
te del código, porque cualquier cosa que esa persona hiciera en el fu- 
turo podía considerarse como inspirada de alguna forma por la tecno- 
logía privada gopher. 

En la reunión de marzo de 1993 del TIETF en Columbus, Ohio, 
que se celebró tras el anuncio, me abordaron en los pasillos: “De 
acuerdo, eso es lo que pasó con el gopher. ¿Va a hacer lo mismo el 
CERN con la WWW?”. Yo escuchaba atentamente las preocupacio- 
nes de la gente y lo que decían que les parecería o no aceptable. Tam- 
bién sudaba copiosamente tras mi aparente tranquilidad. 

Durante el año anterior había estado intentando que el CERN co- 
locase los derechos de propiedad intelectual del código web bajo Li- 
cencia Pública General (GPL), para que otros pudieran usarla, La 
GPL fue desarrollada por Richard Stallman para su Free Software 
Foundation [Fundación de Software Libre], y mientras permitía que 
las cosas se distribuyeran y usasen libremente, había cosas que que- 
daban atadas, como por ejemplo que cualquier modificación tenía 
que entrar bajo la misma GPL. Como consecuencia de la debacle del 
gopher, ya había rumores de que grandes empresas como IBM no per- 
mitiría que el Web entrase en sus instalaciones si había algún tipo de 
licencia, porque eso también sería demasiado incómodo. Y eso incluía 
la GPL. 

El CERN no lo tenía claro todavía. Yo volví de Columbus y cam- 
bié mi petición rápidamente; dije que en lugar de conseguir una GPL 
podríamos poner la tecnología web a disposición del público en gene- 
ral, sin ataduras. 

El 30 de abril Robert y yo recibimos una declaración, con el sello 
del CERN, firmada por uno de los directores, diciendo que el CERN 
accedía a permitir a todo el mundo el uso del protocolo y el código 
web gratuitamente, crear un servidor o un navegador, repartirlo o 
venderlo, sin ningún royalty ni otras cargas. ¡Menos mal! 
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Mi experiencia en el NCSA y el desastre del asunto de las licencias, me 
convenció más que nunca de que era necesario algún tipo de organiza- 
ción para vigilar el desarrollo del Web. El rápido crecimiento del Web 
me daba aún más la razón. El Web estaba empezando a cambiar de 
fase. Algunas personas seguían mandándome e-mails acerca de poner 
en marcha nuevos servidores. Pero otros no; se limitaban a ponerlos 
sin decir nada. El CERN y yo estábamos empezando a esfumarnos 
tras el zumbido de fondo. La actividad del Web estaba creciendo a 
una velocidad constante y exponencial. Era mediados de verano, 
y una vez más tomé nota del número de personas que estaban acce- 
diendo al servidor del CERN, info.cern.ch. Ahora recibía diez mil vi- 
sitas al día. La proporción era increíble y seguía doblándose cada tres 
o cuatro meses, creciendo según un factor de diez cada año, de cien vi- 
sitas al día en el verano de 1991 a mil en el verano de 1992 y diez mil 
en el verano de 1993, 

Ya no tenía que seguir empujando el trineo. Era tiempo de saltar 
sobre él y conducirlo. 

Yo no quería formar un organismo en sí, sino algún tipo de organi- 
zacion que pudiera ayudar a los que desarrollaban los servidores y na- 
vegadores a alcanzar un consenso respecto al modo en que debería 
funcionar el Web. Con Mosaic recogiendo la pelota y corriendo solo 
hacia la línea de gol, y cada vez más usuarios de gopher que tenían en 
cuenta el Web, aumentaba la evidencia de que “el Web” podía divi- 
dirse en diversas secciones: algunas comerciales, algunas académicas; 
algunas gratuitas y algunas no. Esto iría en contra del propósito pri- 
mero de la Red: ser un medio de hipertexto universal y accesible para 
compartir información. 

Hablé con gente del CERN acerca de poner en marcha algún tipo 
de consorcio. También intercambié e-mails con Michael Dertouzos 
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del Laboratorio de Ciencias Informáticas del MIT. A Michael la idea 
le parecía muy bien. Visitaba frecuentemente Europa y su Grecia na- 
tal, y acordamos vernos en Zúrich el uno de febrero de 1994, 

Tomé el tren de Ginebra a Zúrich sin saber muy bien lo que que- 
rría Michael, ni lo que quería yo. Nos encontramos en un agradable 
café en la ciudad vieja, y mientras tomábamos una ternera al estilo de 
Zúrich con róstí, acabamos esbozando los planes para los niveles su- 
periores de un consorcio. Ambos volvimos a nuestras casas a meditar 
sobre nuestras ideas. 

Parecía algo más que casual que la primera WWW Wizards 
Workshop [Taller de Brujos de la WWW] se organizase para sólo un 
mes más tarde... en Cambridge, Massachusetts, a sólo unas manzanas 
del MIT. Lo había organizado Dale Dougherty, de O'Reilly Associa- 
tes, que de nuevo consiguió calladamente reunir al rebaño. 

O'Reilly acababa de publicar el libro de Ed Krol Whole Earth In- 
ternet Catalog [Catálogo de Internet del mundo entero], que era real- 
mente el primer libro que ponía todo aquello de Internet a disposi- 
ción del público. Cuando lo leí en el tren de Chicago en el que iba a 
ver a Tom Bruce, el World Wide Web no ocupaba más que un capítu- 
lo; el resto era acerca de cómo usar los diversos protocolos de Internet 
como FTP, telnet, etc. Pero el tráfico en el Web estaba aumentando y 
el NCSA acababa de poner en circulación versiones de trabajo del na- 
vegador Mosaic para Unix, Windows y el Mac. Dale se preguntaba él 
mismo hacia dónde iba el Web, y creía poder averiguarlo, y quizá tam- 
bién ayudar a la gente para que lo hiciese funcionar de una manera in- 
teligente, a base de reunir a todo el mundo. 

Unas veinticinco personas de las primeras que desarrollaron el 
Web se reunieron en las oficinas de O'Reilly en Cambridge. Estaba 
Lou Montulli, que había adaptado el Lynx para el Web, y su jefe; un 
grupo del NCSA entre los que estaban Eric Bina, Marc Andreessen, 
Chris Wilson, que estaba porteando el Mosaic al PC, y Alex Totic, que 
lo estaba porteando al Mac; Tom Bruce, autor del Cello; Steve Putz de 
Xerox PARC; Pei Wei, autor del Viola; y muchos otros. El objetivo de 
la reunión era definir las cosas más importantes que había que hacer a 
continuación para la comunidad de desarrollo del Web. A su manera 
amable y animosa, Dale nos hizo hablar a todos. Yo hablé de la idea 
general de un consorcio para el Web. Hablamos de cómo podría ser, si 
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debería ser un consorcio, una organización o un club. En un momen- 
to dado, escribí las palabras Web Club en la pizarra... Bueno, era una 
opción. Dirigí una sesión de ideas geniales para hacer una lista de las 
necesidades que surgirían en los meses siguientes, cubriendo las cua- 
tro paredes con ideas agrupadas para que tuvieran algún sentido. 

Este acontecimiento fue la ocasión de reunirse para varios miem- 
bros de la comunidad. Incluso para los devotos recalcitrantes de 1n- 
ternet, es divertido verse cara a cara con personas con las que sólo nos 
hemos comunicado por e-mail. Durante la reunión varias personas co- 
mentaron lo que les sorprendía que Marc, que había sido tan charla- 
tán por Internet, fuese una persona tan callada. Unos cuantos de no- 
sotros tomábamos fotos, y Marc fue prácticamente el único que no 
quiso ser fotografiado. Conseguí sacarle una foto con un teleobjetivo, 
pero a pesar de su tamaño físico y desinhibición para salir a hablar en 
el grupo de noticias www-talk, él y los otros del NCSA eran notable- 
mente tímidos y silenciosos. 

Volví al CERN con una visión más clara de que era necesario un 
consorcio. Entonces un día sonó el teléfono de mi oficina. Era recep- 
ción, diciendo que había cuatro personas de la Digital Equipment 
Corporation, que querían verme. Pero el CERN no era un sitio en el 
que la gente llegase tranquilamente a recepción. Es un lugar interna- 
cional, enorme, la gente tiene que recorrer un largo camino, necesitan 
un acompañante que les guíe. Pero, de pronto, aquel grupo de perso- 
nas con traje se materíializaron allí. Pedí rápidamente una sala de con- 
ferencias que estuviera disponible. Eran tres hombres y una mujer: 
Alan Kotok, el consultor senior; Steve Fink, un hombre de marketing; 
Brian Reed, el gurú de Internet en la DEC por entonces; y Gail Grant, 
del centro de operaciones de la compañía en Silicon Valley. 

Alan había estado impulsando a la DEC en la dirección del Web 
desde que le enseñaran por primera vez un navegador web, y la direc- 
ción había pedido a Steve que reuniese un equipo para evaluar el fu- 
turo de Internet en la DEC. Steve explicó que tendrían que rediseñar 
en gran parte la DEC a causa del Web. Mientras que veían esto como 
una gran oportunidad, estaban preocupados por la dirección que iba 
a tomar el Web, y porque el Web no estaba quizá definido más que 
por especificaciones almacenadas en algún disco que se encontrase en 
alguna parte del CERN. Querían conocer la actitud del CERN respec- 
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to al futuro camino del Web, y si podían estar seguros de que seguiría 
siendo estable aunque evolucionase. 

Les pregunté que cuáles eran sus peticiones y que qué les parecía 
importante. Ellos pensaban que debía haber un organismo neutral ac- 
tuando como convocante. No estaban interesados en hacerse con el 
Web ni tener un control de propiedad sobre él. Pero querían realmen- 
te que hubiera un organismo de vigilancia al que poder adherirse. Se 
preguntaban si el CERN lo iba a llevar a cabo. 

Para mí, aquella fue una reunión en la que escuché, Era un 
tema importante relacionado con qué hacer a continuación. Les dije 
que había hablado con el MIT acerca de formar quizá un grupo de 
control. Podía formarse según el Consorcio X, que había organiza- 
do el MIT para convertir el sistema X-Windows de Bob Scheifler, a 
partir de su diseño inicial, en una plataforma usada por la mayoría 
de los terminales Unix. Al parecer lo consideraron una idea excep- 
cional. 


En octubre había más de dos mil servidores HTTP conocidos, y cier- 
tamente muchos más ocultos. La Comisión Europea, el Fraunhofer 
Gesellschaft y el CERN pusieron en marcha el primer proyecto basa- 
do en el Web de la Unión Europea, llamado Webcore, para difundir 
información tecnológica a través de los países del antiguo bloque so- 
viético en Europa. Luego, en diciembre, los medios se dieron cuenta y 
hubo artículos en importantes publicaciones acerca del Web y Mo- 
saic, y todo empezó a funcionar conjuntamente. 

Mientras tanto, la comunidad de promotores interesados iba cre- 
ciendo. Sería obviamente emocionante convocar una conferencia del 
World Wide Web para reunirlos a una escala mayor de lo que había 
hecho el Wizards Workshop. Yo ya había hablado con Robert de ello, 
y ahora la necesidad era más acuciante. Él consiguió el visto bueno de 
la dirección del CERN para organizar la primera Conferencia Interna- 
cional WWW y celebrarla en el CERN. Robert estaba muy emociona- 
do y comprobó las fechas de ocupación del auditorio y de tres salas de 
reuniones. Sólo había dos fechas disponibles durante los meses si- 
guientes. Él reservó una rápidamente. Volvió y dijo: “Tú no tienes que 
hacer nada. Yo lo haré todo. Pero esta es la fecha en que se tiene que 
celebrar”. 
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Yo dije: “Bien, Robert, muy bien, pero es precisamente la fecha en 
que mi mujer y yo estamos esperando nuestro segundo hijo”. Él se dio 
cuenta de que había cosas que se podían cambiar de fecha y otras que 
no. Suspiró y volvió a ver si la otra fecha seguía disponible. Lo estaba 
pero la fecha, a finales de mayo, era antes que la primera, y eso nos de- 
jaba muy poco tiempo para organizarlo todo. 

Robert se puso a coordinar rápidamente todo lo necesario para 
una conferencia, incluidos los conferenciantes. Una de las primeras 
personas a las que llamó fue a Joseph Hardin, del NCSA. Pero la res- 
puesta de Hardin a Robert fue: “Oh, bueno, estábamos pensando en 
celebrar una conferencia, y mayo es el mes en que pensábamos hacer- 
lo, en Chicago. ¿Os importaría cancelar vuestra conferencia para que 
pudiéramos celebrar la nuestra?”. 

Robert debatió consigo mismo sólo un momento. Era una cues- 
tión de honor y orgullo lo que se planteaba allí, pero también la futura 
dirección del Web. La conferencia era la forma de decirle a todo el 
mundo que nadie debería controlarlo, y que un consorcio podría ayu- 
dar a las partes a estar de acuerdo en el modo de trabajar juntos, a la 
vez que evitar los esfuerzos de cualquier institución o empresa de 
“controlar” las cosas. Pensando que quizás el NCSA estuviera tratan- 
do de ganarnos otra vez por la mano, Robert le dijo a Hardin: “Bueno, 
si habéis planeado vuestra conferencia hace tanto tiempo, ya nos ten- 
dríais que haber hablado de ella a nosotros. Así que, lo siento. Vamos 
a seguir adelante”. Señaló que ya había reservado el espacio y que ha- 
bía pasado el punto de no retorno. El NCSA decidió celebrar una se- 
gunda conferencia WWW en noviembre. 

A medida que avanzaba 1994, surgieron más signos de que el pú- 
blico en general estaba adoptando el Web. Merit Inc., que manejaba 
la columna vertebral de Internet para la Nacional Science Founda- 
tion, midió el uso relativo de los diferentes protocolos en Internet. En 
marzo de 1993 las conexiones web eran el 0,1% del tráfico de Inter- 
net. Esto había llegado a un 1% en septiembre y a un 2,5% en diciem- 
bre. Semejante crecimiento no tenía precedentes en los círculos de In- 
ternet. 

En enero, O'Reilly había anunciado un producto apodado “Inter- 
net en una caja”, que llevaría a Internet y al Web a los hogares. Ya era 
posible que cualquiera descargase, gratis, todos los navegadores, el 
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TCPAP y el software necesario para entrar en Internet y en el Web, 
pero un usuario tenía que saber mucho acerca de cómo configurarlos 
y hacer que funcionasen juntos, lo que era complicado. Ni Internet ni 
el Web habían sido destinados inicialmente para el uso doméstico o 
individual; estaban pensados para universidades, investigadores y or- 
ganizaciones grandes. El producto de O'Reilly-lo reunió todo. Lo úni- 
co que tenía que hacer el usuario era instalarlo en su ordenador y pa- 
gar las tarifas telefónicas por su conexión a Internet. 

Sin embargo, poco después muchos proveedores de Internet em- 
pezaron a surgir: compañías locales que daban acceso a Internet vía 
una llamada de teléfono local. Proporcionaban todo el software que 
requería un suscriptor Eso hizo innecesario el “Internet en una caja”. 
Y fue un claro indicador de la rápida comercialización de la “Red”. 

Un mes escaso más tarde, Navisoft Inc. puso en marcha un nave- 
gador/editor para el PC y el Mac, que recordaba mucho a mi cliente 
original World Wide Web. Navipress, que era como se llamaba, per- 
mitía a una persona navegar por documentos y editarlos al mismo 
tiempo. No era necesario descargar una cosa explícitamente, editarla 
en un modo diferente y luego cargarla otra vez; por fin un navegador 
que también funcionaba como editor. Me alegró oír hablar de él. Nor- 
malmente, cuando hablábamos de los principios del Web, la mayoría 
de la gente no lo entendía. Pero Dave Long y la gente de Navisoft lo 
habían comprendido milagrosamente con sólo leer todo lo que había- 
mos escrito en info.cern.ch y siguiendo las conversaciones de la comu- 
nidad web. Navipress era un auténtico navegador y editor, que.produ- 
cía HTML muy claro. 

Hablé otra vez con Michael Dertouzos acerca de formar un con- 
sorcio. En febrero me invitó al laboratorio del MIT para ver si podía- 
mos fijar los detalles que ambos queríamos. Me llevó a comer al Hyatt, 
que al parecer era el sitio adecuado para las conversaciones serias, El 
portero le conocía tan bien que había un espacio acordonado esperan- 
do el BMW de Michael en cualquier momento. Michael había ayuda- 
do a poner en marcha otras organizaciones de alto nivel, formadas por 
gente académica, de la industria y del gobierno, y suponía que un mo- 
delo similar funcionaría para crear un consorcio web. Pero cuando me 
preguntó dónde quería que residiese esa organización, yo mencioné 
titubeante que no quería que estuviera basada sólo en el MIT; quería 
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que fuese internacional. No quería desertar de Europa para irme a los 
Estados Unidos. Pensaba que debía haber una base en Europa y una 
base en Estados Unidos. : 

Felizmente, eso tenía sentido para Michael. Se alegraba de que el 
LCS fuese parte de lo que él llamó una bestia de dos patas. De ascen- 
dencia griega, Michael había hecho muchas conexiones transatlánti- 
cas durante años y siempre se había interesado en fomentar los esfuer- 
zos conjuntos del Viejo y el Nuevo Mundo. No había encontrado un 
obstáculo, sino uno de los puntos fuertes de Michael. Volvimos al 
LCS sintiendo entusiasmo y simpatía mutua. 

Michael me presentó más tarde a su director asociado, Al Vezza, 
que había ayudado a Bob Scheifler a poner en marcha el X Consor- 
tium y hacerlo funcionar para el LCS durante años. Al me llevó a su 
despacho y me hizo agudas preguntas sobre el fin comercial de un 
consorcio, preguntas para las que yo no tenía respuestas, preguntas 
sobre la organización estructural y el modelo financiero. Afortunada- 
mente, Al tenía todas las respuestas. Había puesto en marcha ese tipo 
de cosas para el X Consortium y estaba encantado de volverlo a hacer. 
El plan del X Consortium había estado tan bien definido que Al acabó 
convenciéndome de que adoptara un modelo similar. El CERN estaba. 
claramente en primera posición para ser el anfitrión europeo. Michael, 
Al y yo habíamos asumido que el CERN aceptaría. Yo volví a Ginebra 
y empecé una serie de conversaciones acerca de que el CERN asumie- 
ra su nuevo papel. 

A medida que avanzaban las conversaciones, Marc Andreessen, 
que había abandonado el NCSA para unirse a Enterprise Integration 
Technology (ETT), conoció al hombre de negocios Jim Clark. Juntos 
habían fundado Mosaic Communication Corp. Los dos contrataron 
rápidamente a Lou Montulli, de Lynx, se hicieron con el equipo prin- 
cipal que desarrolló el Mosaic y se dispusieron a comercializar su na- 
vegador. Pronto se trasladaron a Mountain View, California, y en abril 
de 1994 se llamarían a sí mismos Netscape. 

A pesar de los nuevos artículos que lo definían como el primer 
paso de una revolución en Internet, el comienzo de Netscape fue muy 
natural. El equipo de Mosaic, contrariamente a otros equipos de nave- 
gadores, siempre había operado mucho más como un équipo de desa- 
rrollo de un producto que como un equipo de investigación. Eran mu- 
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cho más conscientes de la marca Mosaic, de las relaciones con los 
clientes, del marketing y de las entregas. El NCSA adoptó deliberada- 
mente el Mosaic para múltiples plataformas de modo que pudiese lle- 
gar a una gran audiencia. Contrariamente al CERN, el NCSA nunca 
dudó un momento de que crear productos comerciales fuese una acti- 
vidad apropiada. Al promocionar las habilidades de Marc, el NCSA 
dio un buen empujón al Mosaic y lo lanzó, desde ser una gran idea vis- 
ta en Viola hasta convertirlo en un producto de primera necesidad 
que iba a acabar estando en todos los escritorios. Andreessen y Clark 
se dispusieron a conquistar agresivamente todo el mercado. Para con- 
seguirlo, usaron una política de marketing sin precedentes: lanzaron 
su producto gratis, para que se pudiera expandir rápida y ampliamen- 
te; lo único que había que hacer era descargarlo de Internet. También 
parecían seguir la política financiera sin precedentes de no tener un 
plan de negocios al principio: decidieron no preocuparse de cuál sería 
el plan hasta que el producto fuera mundialmente famoso y omnipo- 
tente. 

La llegada del software y los servicios web como producto comer- 
cial fue un paso muy importante para el Web. Mucha gente no quería 
usar realmente el Web a menos que estuviesen seguros de poder com- 
prar los productos que necesitaban a una empresa con todos los de- 
partamentos habituales, incluyendo apoyo al cliente. Robert y yo ha- 
bíamos pasado mucho tiempo tratando de convencer a empresas para 
que adquiriesen el Web como producto. Al fin ocurrió. 

La gente empezó a preguntarme si estaba planeando fundar una 
compañía. Detrás de esta pregunta, quizá se estuvieran preguntando 
si no tenía la sensación de que Marc Andreessen y Jim Clark me ha- 
bían quitado la alfombra de debajo de los pies. Naturalmente, yo tenía 
varias opciones aparte de poner en marcha un consorcio. En realidad 
había pensado en fundar una empresa con el nombre de Websoft, 
para hacer lo mismo que Netscape (el nombre lo tomó más tarde otra 
empresa). Pero en aquel momento, poner en marcha una compañía 
no era ninguna garantía de futuras riquezas. Era un riesgo financiero 
como cualquier comienzo, y en este caso un riesgo considerable, ya 
que ni siquiera había aún un mercado claro. 

Es más, mi misión primaria fue asegurarme de que el Web que ha- 
bía creado seguiría evolucionando. Aún había muchas cosas que po- 
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dían salir mal. Podía haberse desvanecido, ser sustituido por un siste- 
ma diferente, haberse fragmentado o cambiado su naturaleza de 
modo que dejara de existir como medio universal. Recordé lo que ha- 
bía dicho una vez Phil Gross, presidente del IETE, acerca del gopher, 
cuando aún estaba subiendo su popularidad: “Las cosas pueden 
adoptarse rápidamente en Internet, pero también pueden abandonar- 
se rápidamente”. Mi motivación era estar seguro de que el Web llega- 
ría a ser lo que originalmente pretendí que fuera: un medio universal 
para compartir información. Fundar una empresa no contribuiría en 
mucho a lograr este objetivo, y me habría arriesgado a provocar com- 
petencia, lo que podía haber convertido al Web en un puñado de pro- 
ductos privados. Teóricamente, habría sido posible haber dejado que 
la tecnología fuera de libre uso, pero el rápido fin del gopher lo desa- 
consejaba. 

También me di cuenta de que siguiendo el camino del consorcio, 
podía mantener un punto de vista neutral, lo que me permitiría tener 
una visión mucho más clara de aquella escena tan espectacular y en 
evolución de lo que me permitiría una posición como empresario. 
Quería ver proliferar al Web, no pasarme la vida preocupado por el 
lanzamiento de un producto. Dirigit ún consorcio limitaría mis opi- 
niones públicas debido a la confidencialidad y a la necesidad de ser 
neutral, pero estaría libre para pensar realmente acerca de qué era lo 
mejor para el mundo, y no en lo que sería mejor para los intereses co- 
merciales. También sería libre de detentar una influencia persuasiva 
en las futuras direcciones técnicas del Web. 

Supongo que podía, como alternativa, haber seguido una carrera 
académica, ir a una universidad cualquiera como profesor adjunto. 
Pero nunca había hecho el doctorado, así que incluso en el CERN, el 
grado que tenía al entrar y el grado en el que me mantuve durante 
toda mi carrera, no era suficiente. Tendría que haber pasado una bue- 
na cantidad de tiempo haciendo el doctorado en una matería bastante 
limitada. Desde luego, no tenía tiempo. Y estrechar mis horizontes se- 
tía sin duda saltar del trineo que había conseguido poner en marcha. 

Una opción más tentadora era la de unirme al grupo de investiga- 
ción de una gran empresa benévola, lo que me habría permitido seguir 
investigando aquello que me resultara interesante, pero también parti- 
cipar en el movimiento industrial para conseguir que los productos 
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web entrasen en el mercado y en las vidas de la gente. Hablé con va- 
rias empresas y visité unos cuantos laboratorios para evaluar esa posi- 
bilidad, pero ninguno me convenció. 

Fundar un consorcio, por tanto, representaba la mejor manera 
para mí de ver a la comunidad web expandirse por más áreas cada vez. 
Mi decisión de no convertir el Web.en mi propia empresa comercial 
no era un acto de altruismo o desprecio por el dinero, de lo que sería 
posteriormente acusado. 


La prensa hablaba mucho de Mosaic Communications, y mientras 
tanto la primera conferencia World Wide Web se estaba acercando rá- 
pidamente. Robert dedicó toda su atención a llevar a cabo un prome- 
tedor acontecimiento. 

La conferencia empezó en el CERN el 25 de mayo, y duraría tres 
días. Acudió muchísima gente. El auditorio albergaba a unas trescien- 
tas personas. Limitamos la asistencia a trescientos, pero acabamos con 
trescientos cincuenta tras admitir a miembros de la prensa, y otros que 
aparecieron de repente, prueba de lo que había crecido el Web. 

Los estudiantes voluntarios, a los que Robert había convocado 
para que ayudasen en la conferencia, se encontraban en la zona de ad- 
misiones. Robert y yo, naturalmente, estábamos por todos lados tra- 
tando de arreglar los asuntos de última hora. Pero cuando fui a la sala 
de conferencias, los estudiantes no me dejaron entrar, porque la con- 
ferencia no había empezado todavía. Me costó mucho tiempo conven- 
cerles de que yo era parte de la organización que estaba dando la con- 
ferencia. 

Tal como prometió, Robert lo había organizado todo, y excepto 
por las prisas de última hora, yo no tuve que hacer nada más que ir y 
hablar. El ambiente de las salas de reunión era emocionante y aún así. 
cercano. Había gente de todas clases reunida por su entusiasmo por el 
Web. Las charlas que se daban en el pequeño auditorio estaban reple- 
tas de personas. Como era la primera conferencia de ese tipo, mucha 
gente que había estado relacionándose sólo por e-mail se estaba cono- 
ciendo por primera vez en persona. Y por primera vez la gente que es- 
taba desarrollando el Web se reunía con toda clase de gente que esta- 
ba usándolo de todas las maneras posibles. Las conexiones eran 
eléctricas. Por ejemplo, estaba Borre Ludvigsen, que tenía un servidor 
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casero que permitía a la gente visitar su casa, ver un plano de ella, ver 
dónde estaban los ordenadores y mirar sus estanterías. Había puesto 
su servidor en una línea telefónica especial proporcionada por la com- 
pañía noruega de teléfonos como parte de un experimento. Estaba ha- 
blando con gente que pensaba que podía adaptar su idea para aplica- 
ciones sanitarias. La emoción, el buen ambiente y el fervor por 
mejorar el Web inspiraron a los periodistas que llamaron a la reunión, 
un poco exageradamente, “el Woodstock del Web”. 

* En el tiempo que duró una sesión en una de las salas de reuniones, 
se estableció la agenda del HTML para los años siguientes: cómo in- 
corporar tablas, matemáticas y el uso de gráficos e imágenes fotográ- 
ficas. Aunque cualquier cosa que hubiera en un servidor FTP de In- 
ternet estuviera disponible en el Web, el HTTP había despegado 
completamente como una alternativa más eficaz, pero necesitaba mu- 
cha más optimización para mantenerse al nivel de la cada vez mayor 
demanda para conseguir páginas web frecuentemente de un servidor 
en rápida sucesión, y hacerse con todos los gráficos incluidos en una 
página. Dave Raggett propuso un “Lenguaje de “Etiquetas” de Reali- 
dad Virtual”, una idea que recogió y puso en marcha Mark Pesce, ha- 
ciendo que toda la comunidad hiciese 3D en el Web y definiera el 
VRML. 

La única vez que me sentí un poco incómodo fue cuando di la 
charla final. Hablé acerca de varios aspectos técnicos, lo que estaba 
muy bien. Anuncié el futuro consorcio, lo que estaba muy bien. Pero 
entonces acabé señalando que, al igual que los científicos, la gente de 
la comunidad de desarrollo del Web debía ser consciente ética y mo- 
ralmente de lo que estaba haciendo. Pensé que esto podía ser inter- 
pretado como un poco fuera de lugar por los más extravagantes, pero 
las personas presentes eran las que estaban creando el Web ahora mis- 
mo, y por tanto eran las únicas que podían estar seguras de que lo que 
los sistemas producían fuera apropiado para una sociedad razonable y 
justa. A pesar de mi temblor, me acogieron muy bien, y me sentí muy 
alegre por haberlo dicho. La conferencia señaló la primera vez que 
la gente que estaba cambiando el mundo con el Web se había reunido 
para tomar una dirección determinada sobre la responsabilidad y para 
decidir el modo en que íbamos a usar realmente el nuevo medio. Era una 
importante dirección que había que establecer en aquel momento. 
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Me fui a casa muy contento. Por muy emocionante que fuera todo 
aquello, quedó minimizado en mi vida personal por la llegada de 
nuestro segundo hijo en junio. La vida familiar continuaba y durante 
un tiempo parecía que el MIT se hubiera atascado en sus preparativos 
del Consorcio WWW. Entonces Al Vezza empezó a llamarme a casa 
por las noches para hablar de los detalles. Las conversaciones pare- 
cían aún más extrañas por la desconexión cultural. Nuestra pequeña 
casa prefabricada estaba en un pequeño pueblo francés a unos kiló- 
metros de la frontera suiza. La vista desde nuestro jardín delantero se 
extendía hasta Ginebra y el Mont Blanc. Desde el jardín de atrás, don- 
de a menudo cenábamos, teníamos una vista de las montañas del Jura, 
las vacas pastando en los prados. Dada la diferencia horaria con Mas- 
sachusetts, allí era donde yo solía estar cuando llamaba Al. Llevaba 
puestos unos pantalones cortos y estaba sentado al sol. Al, que segura- 
mente llevaba un traje gris, estaría sentado en un edificio de oficinas 
de cemento, con aire acondicionado, en Cambridge. Á veces era difí- 
cil contactar a través de ese abismo. 


Una noche de principios de julio, sonó el teléfono. Era Al, que estaba 
muy serio. Quería saber si podía ponerme un fax inmediatamente. 
Dijo que acababa de conseguir el visto bueno del MIT para formar el 
consorcio. El LCS estaba preparado para contratarme como miembro 
del personal a tiempo total. Tenía una carta a tal efecto y quería saber 
cuándo podía empezar yo. 

Sólo faltaban diez días para que nos fuéramos de vacaciones. No 
teníamos planeada ninguna fecha para después, porque el proceso de 
conseguir los detalles adecuados del MIT parecía a veces que no tenía 
un final a la vista. Como parecía que el MIT se había puesto ahora en 
marcha de verdad, no había razón alguna para esperar. El 1 de sep- : 
tiembre parecía una fecha adecuada para empezar. Serían sólo diez ' 
días después de que hubiéramos vuelto de vacaciones, pero quería- 
mos estar en los Estados Unidos al principio del curso escolar. 

La siguiente llamada de Al fue el 14 de julio, el día de la Bastilla. 
Como de costumbre, en nuestro pueblo se celebraba con fuegos artifi- 
ciales, lanzados desde un prado que estaba enfrente de nuestra casa. 
Me di cuenta de que no podía hablar completamente en serio con Al, 
y me pregunté si él lo entendería. Allí estábamos, contemplando los 


Cambios 83 


fuegos artificiales en nuestro pequeño pueblo del campo francés, que 
brillaban sobre el lago y los Alpes. Con las explosiones, la conversa- 
ción era casi inaudible, 

Mi mujer y yo estábamos haciendo las maletas para las vacaciones. 
Aunque supusimos que podríamos volver para organizar nuestras co- 
sas, decidimos que si había dudas acerca de si llevarnos una cosa o no, 
nos la llevaríamos. Y así nos marchamos, con una niña pequeña, un 
bebé y un montón de amigos acompañándonos al aeropuerto con die- 
ciséis cajas y maletas. Mi familia nunca volvió. Yo volví durante diez 
días para vender, con la ayuda de los amigos, los coches y la casa. 

Mientras tanto, animados por George Metakides en Bruselas, el 
MIT y el CERN cerraron un acuerdo para poner en marcha el Con- 
sorcio World Wide Web. Fue anunciado en Boston por Martin Ban- 
gemann, uno de los comisarios de la Comisión Europea, que estaba a 
cargo del desarrollo del plan de la CE para la Sociedad de Informa- 
ción Global. Hubo una conferencia de prensa. La Associated Press 
escribió un artículo. Á continuación hubo informes en el Wall Street 
Journal, el Boston Globe y otros periódicos importantes. A Mike Sen- 
dall y Robert Cailliau se había unido Francois Fluckiger, que dirigiría 
el equipo del consorcio en el CERN. Seguía sin estar muy claro si el 
consorcio encajaría allí, ya que era algo nuevo. Estaba claro que el 
MIT lo controlaba todo bastante, moviéndose más deprisa, con más 
experiencia y contactos relevantes. Algunas personas expresaron en 
Europa la preocupación de que la tecnología del Web se desplazase 
hacia el oeste, dejando atrás a Europa. Yo sabía que tenía que mover- 
me hacia el centro de gravedad de Internet, que era Estados Unidos. 
El gobierno americano se felicitaría por el éxito de los fondos para la 
investigación que llevaron hasta Internet, y Europa podía felicitarse 
por el dinero que los contribuyentes se gastaban en el CERN. 

Abandoné Ginebra para ir al MIT. A América. Al Consorcio del 
World Wide Web. Y a un nuevo papel como contribuyente a la evolu- 
ción del Web. 


8. CONSORCIO 


Cuando llegué al Laboratorio de Ciencias Informáticas del MIT, me 
acomodé en un pasillo con dos puertas y sin ventanas cerca del despa- 
cho de Michael Dertouzos y Al Vezza. Aunque tener un despacho 
propio hubiera sido agradable, este arreglo me venía muy bien porque 
nos permitía trabajar juntos de manera muy inmediata; además ellos 
podían mantenerme vigilado. 

No había tenido tiempo de comprarme un coche aún, así que iba 
en autobús desde nuestra casa provisional. Ir hasta el trabajo en la ut- 
bana Cambridge era muy diferente del recorrido en la Francia rural, 
pero era otoño y el paseo en autobús me permitió disfrutar de los co- 
lores otoñales de Nueva Inglaterra. También me permitió pensar en 
mi nuevo papel. 

Aunque sabía que me vería obligado a introducir algún tipo de es- 
tructura, yo quería que el consorcio funcionase de un modo que refle- 
jase una existencia web verosímil. El Web no sería una herramienta 
aislada utilizada por personas en su vida, o incluso un espejo de su 
vida real; tenía que ser parte del tejido de la telaraña fweb] de la vida 
que todos contribuimos a tejer. 

La escena web estaba empezando a llenarse de una mezcla coloris- 
ta de diferentes tipos de gente, organizaciones, y también preocupa- 
ciones. El consorcio también lo iba a estar. Sería su propio tejido, y de- 

ería apoyar al gran Web, que ayudaría a sostener a la telaraña de la 
vida. 

Yo quería que el consorcio funcionase en un proceso abierto como 
el del IETE, pero más rápido y eficaz, porque nosotros queríamos mo- 
vernos más deprisa. Yo también quería que hubiera una atmósfera 
que permitiera a los individuos, que representaban a sus empresas u 
organizaciones, expresar sus ideas personales y encontraran caminos 
para alcanzar un entendimiento común. Siempre habría personas que 
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no estuvieran de acuerdo, y también habría apoyos al progreso. Nos 
acercaríamos más al auténtico consenso, quizá sin lograrlo nunca 
completamente, pero los avances serían estupendos. 

Este diseño libre podría crear tensión entre el hecho de que yo 
fuera un directivo y el hecho de dejar que el consorcio fuera un espa- 
cio muy plano de respeto entre iguales y decisiones conjuntas. Podía 
crear tensiones entre los miembros del consorcio, que tendrían que 
tomar decisiones pero también ceñirse a un proceso democrático. Me 
llamó la atención el que esas decisiones pudieran convertir al consor- 
cio en un terreno experimental para los méritos relativos de las socie- 
dades tipo Web o tipo árbol. Yo estaba deseando poner en marcha el 
experimento. 

Las conferencias WWW continuaron semestralmente en Darms- 
tadt, Boston y París, y los institutos académicos que los albergaban 
fundaron el Comité Internacional de Conferencias del World Wide 
Web como una organización no lucrativa, para continuar la serie de 
conferencias, con Robert como presidente. En lo que se refería a los 
negocios, Netscape estaba trabajando con furia para sacar la primera 
versión comercial de su navegador para finales de año. Bill Gates y 
Microsoft, que no se habían interesado al principio en Internet y el 
Web, se dieron cuenta de que se estaban perdiendo algo bueno. Gates 
puso a gente a desarrollar un navegador. Microsoft también investiga- 
ba el desarrollo de un servicio en línea que pudiera competir con 
America Online, CompuServe y Prodigy. 

El momento en que cada uno estuviera desarrollando determina- 
da tecnología y cuándo una persona estuviera trabajando con otra, de- 
terminaría el curso de los hechos durante los años siguientes. En abril 
de 1994 Gates decidió que la siguiente versión del sistema operativo 
de Microsoft, Windows 95, incluiría software para acceder a Internet. 
La decisión llegó sólo unas semanas después de que Clark y Andrees- 
sen formasen Mosaic Communications. Gates escribió un memorán- 
dum a los empleados de Microsoft diciendo que Internet constituiría 
una nueva e importante parte de la estrategia de la compañía. Si Gates 
hubiera tomado la decisión dos meses antes, ¿habría contratado a la 
misma gente del NCSA que acababa de contratar Mosaic? 

El Web se estaba convirtiendo en un negocio. En lugar de desatro- 
llar su propio código web, Microsoft autorizó un código de navegador 
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de una pequeña filial del NCSA llamada Spyelass. El coste fue de dos 
millones de dólares, más dinero del que cualquiera de los que había- 
mos estado implicados en el tema desde el principio hubiéramos po- 
dido soñar. 

En noviembre, empezaron las grandes campañas de marketing. 
En Comdex, la feria semestral de informática, Microsoft anunció con 
gran fanfarria que iba a ser lanzado su servicio en línea, Microsoft 
Network (o MSN), y que el software para acceder a él y usarlo iba a 
ser parte de Windows 95. En la misma conferencia Jim Clark anunció 
públicamente que Mosaic Communications iba a cambiar de nombre 
y llamarse Netscape. El NCSA estaba molesto porque Clark y Andre- 
essen usaban su nombre de Software, Mosaic, como marca comercial, 
y cuando los dos contrataron a gente del NCSA, éstos se lo tomaron 
como una ofensa. Llegaron a un acuerdo amistoso que le costó a la 
compañía recién fundada cerca de tres millones de dólares en gastos; 
además, tenían que buscar un nuevo nombre, que fue Netscape. 


Al y yo estábamos hablando del nombre de la organización incipiente, 
y nos pusimos de acuerdo en World Wide Web Consortium o, para 
resumir, W3C. Algunos de los iconos aún tienen restos de la “O” de 
Organización (“W30” World Wide Web Organization), que se man- 
tuvo durante un tiempo. 

Mientras preparaba una agenda técnica, Al iba admitiendo miem- 
bros con gran energía. Los de Digital Equipment que me habían sor- 
prendido con su visita al CERN, estuvieron entre los primeros en la 
lista de Al. Se adhirieron, y gente de otras empresas —desde los prin- 
cipiantes Netscape hasta los bien establecidos, como Hewlett-Pac- 
kard e IBM— les siguieron rápidamente. 

La pertenencia al consorcio estaba abierta a cualquier organiza- 
ción; comercial, educativa o gubernamental, ya fuese lucrativa o no. 
La cuota anual para ser miembro de pleno derecho era de cincuenta 
mil dólares; para miembros afiliados, de cinco mil dólares. No había 
diferencias en los beneficios, pero para ser un miembro afiliado una 
organización tenía que ser gubernamental o no lucrativa, o ser una 
compañía independiente con beneficios de menos de cincuenta millo- 
nes de dólares. Netscape se adhirió por cincuenta mil dólares, a pesar 
de tener el estatus de afiliado; insistieron en que se adherían como 
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una gran empresa en principio. Los miembros tenían que comprome- 
terse a pertenecer durante tres años, después de los cuales podían re- 
novar el contrato anualmente. A su vez, los miembros podían asistir a 
cualquier reunión libremente y sentarse en cualquier grupo de trabajo 
o cualquier otra cosa que organizáramos. También tendrían acceso 
exclusivo a información en profundidad de todas las actividades que 
estuvieran en marcha, estuvieran directamente implicados o no. 

Aunque no teníamos un lema por entonces, el propósito del con- 
sorcio era “conducir al Web a su más alto potencial”, en primer lugar 
desarrollando protocolos comunes para destacar la interoperabilidad 
y evolución del Web. Para hacerlo, estaríamos a la cabeza de una sig- 
nificativa oleada de aplicaciones, servicios y cambios sociales, cum- 
pliendo una combinación única de papeles tradicionalmente adscritos 
a organizaciones muy diferentes. 

Al igual que el TETF, el W3C desarrollaría especificaciones técni- 
cas abiertas. Contrariamente al IETE el W3C tendría un personal re- 
ducido a tiempo completo para ayudar a diseñar y desarrollar el códi- 
go cuando fuera necesario. Igual que los consorcios industriales, el 
W3C representaría el poder y la autoridad de millones de empresa- 
rios, investigadores y usuarios. Y al igual que las instituciones miem- 
bros de investigación, apoyaría los más recientes avances en tecnolo- 
gía de la información. 

El consorcio también se molestaría en seguir siendo un foro “neu- 
tral de venta” para sus miembros. Una pequeña cantidad de personal 
que residiría en el Laboratorio de Ciencias Informáticas y en sedes en 
Europa y Asia produciría especificaciones y códigos de muestra, que 
los miembros —o cualquiera, en realidad— podrían coger y usar para 
cualquier propósito, incluyendo productos comerciales, sin tener que 
pagar. Los fondos del consorcio procedentes de derechos (e, inicial- 
mente, dinero público para investigaciones) garantizarían estos es- 
fuerzos. 

También habría un Comité de Asesores, que incluiría un represen- 
tante oficial de cada organización miembro, que serviría como el pri- 
mer nexo de unión entre esa organización y el W3C. El papel del co- 
mité consistiría en ofrecer asesoramiento sobre el progreso general y 
la dirección que estuviera tomando el consorcio. Yo sería el director 
del consorcio y Al el presidente. 
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La mayoría de las asociaciones que se apuntaban eran empresas 
interesadas sobre todo en hacer avanzar la tecnología para su propio 
beneficio. La naturaleza competitiva del grupo sería el motor de los 
desarrollos y siempre haría participar a todo el mundo en el tema si- 
guiente. Pero los miembros también sabían que la colaboración era la 
manera más eficaz de que todo el mundo tuviera una parte del cada 
vez mayor pastel, 

Aunque el consorcio se consideró en principio como un grupo in- 
dustrial, los gobiernos de Estados Unidos y Europa le apoyaron. De 
hecho, el Departamento de Proyectos de Investigación Avanzada en 
Defensa de Estados Unidos proporcionó dinero, en parte porque íba- 
mos a construir puentes entre la investigación académica y la indus- 
tria. Martin Bangemann, el comisario de la Comisión Europea, tuvo 
una reunión con los gobiernos europeos, que decidieron apoyar la co- 
ordinación por parte del CERN de la parte europea del consorcio. 

Como era de prever, uno de los primeros pasos que di en el MIT 
fue establecer un servidor web. Saqué una copia de toda la documen- 
tación y especificaciones web existentes del servidor info.cern.ch del 
CERN. La nueva dirección web era http://wiww.103.0rg. El CERN 
mantendría info.cern.ch como dirección de tránsito. 


Apenas había llegado al MIT cuando me enviaron a Edimburgo, Es- 
cocia, para la Conferencia Europea sobre Tecnología de Hipermedios 
que se iba a celebrar. Estaba dirigida por lan Ritchie, de Owl, a quien 
yo había intentado convencer cuatro años antes para que desarrollara 
un navegador web como parte del producto de hipertexto de Owl, 
Guide. Allí fue donde vi a Doug Engelbert enseñar el vídeo de su sis- 
tema original NLS. A pesar de la subida del Web, la comunidad 
SGML seguía criticando al HTML como un subproducto inferior, y 
proponiendo que el Web adoptase todo el SGML., A otros les parecía 
que el HTML debería ser desconectado del torpe mundo del SGML y 
mantenerse limpio y simple. 

Dale Dougherty, de O'Reilly Associates, que había reunido a los 
primeros creadores web en el primer taller Wizards y en otras reunio- 
nes, vio una tercera alternativa. Tras una sesión en la conferencia, 
unos cuantos de nosotros nos fuimos a un pub del lugar. Mientras es- 
tábamos sentados en nuestros taburetes tomando cerveza, Dale empe- 
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zÓ a contarle a todo el mundo que, en esencia, la comunidad SGML 
estaba pasada de moda y que el HTML acabatía siendo más fuerte. Le 
parecía que no teníamos por qué aceptar el mundo SGML al por ma- 
yor o ignorarlo completamente. En voz baja, con una sonrisa, Dale 
empezó diciendo: “Podemos cambiarlo”. Siguió repitiendo la frase 
como si fuera un mantra. “Podemos cambiarlo.” 

Allí mismo se decidió ajustar el SGML. Para la comunidad 
HTML, la controversia se convirtió rápidamente en algo muy emocio- 
nante, que mantenía la cosa funcionando. Y gran parte de la comuni- 
dad de documentación, harta también de muchos aspectos del 
SGML, simpatizó con ellos. 

Comparada con todo el dramatismo que estaba teniendo lugar en 
los procesos de formación de las compañías web, esta controversia 
puede parecer un punto técnico esotérico. Pero los Jim Clark y Bill 
Gates de este mundo no tendrían que tomar grandes decisiones de ne- 
gocios a menos que se tomaran decisiones específicas como la relación 
entre el HTML con el SGML. Los empresarios y gente de marketing 
que pensaban que estaban “conduciendo” el Web no tendrían nada 
que conducir. 

En octubre de 1994, Netscape publicó la primera versión de su 
navegador, llamado Mozilla Era una versión “beta” o de prueba, lan- 
zada para que la gente en Internet la probara y mandase sugerencias 
para mejorarla. Igual que había hecho con Mosaic, Andreessen lanzó 
mensajes sobre Mozilla a los grupos de noticias y los usuarios se hicie- 
ron con él, 

Mientras tanto, Ari Luotonen, el estudiante finlandés del proyecto 
Erwise que Robert había traído al CERN, estaba produciendo código 
HTTP para el CERN. Lo hizo fácil de instalar, con documentación 
acerca de cómo usarlo. Cuando acabó su estancia como estudiante en 
el CERN, se unió a Netscape para trabajar en el software de su servi- 
dor. El otro estudiante que estaba en el CERN, Henrik Frystyk Niel- 
sen, se unió a nosotros en el consorcio. Sería una de las personas que 
haría el trabajo fundamental para la siguiente mejora del protocolo de 
hipertexto, el HTTP 1.1. 

A medida que se iban añadiendo miembros al consorcio, ellos 
mismos nos decían a dónde se querían dirigir en primer lugar. Una de 
las prioridades era la seguridad en Web. La información, como por 
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ejemplo los números de tarjetas de crédito, enviada por el Web, tenía 
que ser salvaguardada. Netscape estaba especialmente interesado por- 
que tenían previsto un trato con la enorme MCI para distribuir el na- 
vegador de Netscape en el nuevo servicio de Internet de MCTI, que se 
pondría en marcha en enero. El software de Netscape, llamado Secure 
Sockets Layer [Instalador de Enchufes de Seguridad (SSL), protege- 
ría las compras con tarjeta de crédito en el centro de compras en línea 
previsto por MCI. Como le parecía que SSL era una ventaja competi- 
tiva y creía que W3C no estaba todavía funcionando de verdad, Nets- 
cape decidió no esperar y desarrolló el software de manera indepen- 
diente. Éste fue uno de los primeros programas que permitieron al 
comercio electrónico ganar credibilidad. 

Con tantas novedades, el otoño pasó rápidamente. De pronto es- 
tábamos en diciembre de 1994. En tres cortos días, tuvieron lugar 
grandes acontecimientos que alterarían para siempre el futuro del 
Web: los miembros del consorcio se reunieron por primera vez; Nets- 
cape lanzó la versión comercial de su navegador; y el CERN decidió 
después de todo no hospedar la página W3C en su servidor. Aquel tri- 
neo que había estado empujando desde la línea de salida desde hacía 
tanto tiempo estaba ahora disparado cuesta abajo. 


El 14 de diciembre, en el LCS, el consorcio World Wide Web tuvo la 
primera reunión de su Comité de Asesores, La reunión fue muy cot- 
dial y bastante reducida, con sólo unas veinticinco personas. Competi- 
dores en el mercado, los representantes trajeron sus preocupaciones 
sobre la fragmentación potencial del HTML. Esto se consideraba como 
una gran amenaza a toda la comunidad. Se propusieron tantas exten- 
siones al HTML que se necesitaba realmente uno estándar. Luchamos 
con los términos; si el consorcio debería en realidad establecer un “es- 
tándar” o sencillamente lanzar una “recomendación” formal. Escogi- 
mos la última opción para indicar que conseguir “un consenso preli- 
minar y un código de funcionamiento” —la máxima de Internet de 
ponerse de acuerdo sobre un programa ejecutable y distribuirlo para 
que se probase— era el nivel en el que queríamos trabajar. También 
tuvimos que movernos deprisa, y no queríamos que nos hundieran los 
largos procesos de votaciones internacionales que requerían la apro- 
bación de los estándar ya existentes. Estaba empezando a estar claro 


92 Tejiendo la Red 


que dirigir el consorcio iba a ser siempre un acto de equilibrio entre 
permanecer todo lo abierto que se pudiera y avanzar a la velocidad 
exigida por la tecnología. 

- También decidimos que si íbamos a desarrollar protocolos abier- 
tos y comunes e ir por delante de las aplicaciones, tendríamos que 
apoyar un esfuerzo continuo, en primer lugar por parte del personal, 
para crear un conjunto de herramientas web que pudiéramos usar no- 
sotros mismos para demostrar nuevas ideas y experimentar con espe- 
cificaciones propuestas. Inicialmente eso significaba adoptar un nave- 
gador y un servidor que estuviesen un poco adelantados a su tiempo. 
Acordamos usar el navegador Arena de Dave Raggett y el servidor del 
CERN como elementos de prueba. Ciertamente, pondríamos esas y 
cualquier otras herramientas a la libre disposición de cualquiera. Lo 
único que tenía que hacer la gente era acceder a la parte pública del si- 
tio web W3C y descargar un programa. 

El auténtico arte del consorcio sería encontrar los acuerdos míni- 
mos, o protocolos, que cualquiera pudiera necesitar para hacer que el 
Web funcionase por Internet. Este proceso no colocaba al consorcio 
en una posición de control; no era más que proporcionar un lugar a la 
gente para que fuera allí y alcanzase un consenso. En aquellos prime- 
ros días, antes de que desarrollásemos procesos más formales, si un 
miembro no quería formar parte de una iniciativa determinada, el re- 
presentante de dicho miembro no acudía a esa reunión. Y si la gente 
no podía ponerse de acuerdo tras serios esfuerzos, abandonaríamos el 
tema. 

Ya fuera inspirados por deseos de libre mercado o por ideales hu- 
manístas, todos sentíamos que el control era una perspectiva equivo- 
cada. Dejé claro que yo había diseñado el Web para que no hubiera un 
lugar centralizado en el que alguien tuviese que “registrar” un nuevo 
servidor, o conseguir la aprobación de sus contenidos. Cualquiera de- 
bería poder hacer un servidor y poner en él lo que quisiera. Filosófica- 
mente, si el Web iba a ser un recurso universal, tenía que poder crecer 
de una manera ilimitada. Técnicamente, si había un punto de control 
centralizado, se convertiría rápidamente en un cuello de botella que 
restringiría el crecimiento del Web, y el Web nunca aumentaría pro- 
porcionalmente. El que estuviera “fuera de control” era muy impor- 
tante. 
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El sistema telefónico internacional ofrece una analogía bastante 
aceptable. La razón por la que podemos enchufar un teléfono práctica- 
mente en cualquier lugar del mundo es porque la industria se puso de 
acuerdo en determinados interfaces estándar. Los voltajes y las señales 
de la línea son casi idénticos en todas partes. Y con un adaptador ade- 
cuado, podemos conectar entre sí un gran número de aparatos de dife- 
rentes compañías que envían toda clase de información, desde la voz 
hasta el fax o el vídeo. El sistema telefónico define lo que es necesario, 
pero luego deja libre el modo en que se utilice a los aparatos. Eso era lo 
que necesitábamos para los ordenadores que estuvieran en el Web. 

El 15 de diciembre, el día después de la primera reunión del con- 
sorcio, Netscape lanzó la primera versión comercial de Mozilla, re- 
bautizada Navigator 1.0. Era compatible con el sistema operativo 
Windows de Microsoft, el sistema X-Windows de Unix, y el Macin- 
tosh. El navegador era significativo, no tanto por sus características 
técnicas, sino por el modo en que Netscape lo lanzó. En lugar de en- 
volverlo y distribuirlo, Netscape lo lanzó en Internet. Y en lugar de 
cobratlo, era gratis. En unos meses, la mayoría de la gente que estaba 
en Internet lo estaba usando. 

Andreessen estaba siguiendo el modelo según el cual se había lan- 
zado todo el software web previo, pero esta vez el software provenía 
de una empresa comercial que se suponía que debía ganar dinero, La 
gente se preguntaba de dónde vendrían los beneficios. 

Andreessen y Clark se habían dado cuenta de que los navegadores 
se iban a convertir rápidamente en un bien de uso común. El NCSA ha- 
bía adquirido los derechos del código Mosaic para Otras empresas re- 
cién creadas, y Microsoft estaba desarrollando su propio navegador. 
Netscape no podía esperar ganarse la vida con el mercado de los nave- 
gadores. Lo que podía hacer era sacar su navegador antes que los de- 
más. Si era aceptado rápida y ampliamente, la compañía tendría una 
plataforma desde la que lanzar otros productos que pudiera cobrar. 
También atraería a millones de personas a la página de entrada de Net- 
scape, la primera pantalla por defecto cuando se abría el Navigator. Allí 
Netscape podía mostrar anuncios de compañías que pagasen por llegar 
a una gran cantidad de gente. El sitio también informaría instantánea- 
mente a los navegadores de los demás servicios de. Netscape, por los 
que la compañía podría cobrar. Netscape también cobraría a empresas 
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por una utilización comercial del navegador, que fuese más potente, 
y por poner en marcha y apoyar a un servidor web de la compañía. 

Al tomar esta postura, Netscape estaba reconociendo sabiamente 
que, en el Web, era más beneficioso ser una compañía de servicios que 
una compañía de software. Andreessen y Clark podían no haberlo te- 
nido claro desde el principio, sin embargo, porque a la-gente que des- 
cargaba el navegador se le decía que podían usarlo gratis sólo durante 
tres meses. Después se esperaba que pagasen, o estarían violando el 
acuerdo de licencia. Yo no sabía qué reacciones se estaba encontrando 
Netscape ante esto. Supuse que algunas personas pagarían, pero que 
muchas no, y sencillamente descargaban la siguiente versión del soft- 
ware, que también resultaba ser gratis. Netscape permitía que esto su- 
cediera por miedo a perder admiradores de otros navegadores, y a me- 
dida que pasaba el tiempo sus peticiones de cobro se minimizaron. 

Este enfoque estableció el punto de vista que tendrían que tener 
las siguientes compañías web: lanzar versiones beta para que se vieran, 
lo que colocaba un programa de software naciente en las manos de 
cientos de usuarios profesionales y aficionados, que enviarían (gratui- 
tamente) sugerencias para mejorarlo; repartir software para conseguir 
clientes; distribuir el software de manera rápida y barata por Internet; 
y luego tratar de ganar dinero con los millones de visitantes a través de 
los anuncios o servicios. 

El 16 de diciembre de 1994, el tercer día de una semana increíble, 
el CERN anunció noticias muy importantes. Tras negociar durante va- 
ríos años, el Consejo del CERN había aprobado unánimemente la 
construcción del Large Hadron Collider [Gran Colisionador de Ha- 
drón], un nuevo acelerador. Iba a ser el nuevo salto hacia la investiga- 
ción de las partículas aún más pequeñas de la materia. Pronto me en- 
teré, sin embargo, de que para lograr un proyecto tan gigantesco el 
CERN tendría que imponer unas condiciones presupuestarias muy 
estrictas en la organización. Ningún programa que no fuese impres- 
cindible para la física de alta energía podía ser apoyado. Eso significa- 
ba que el CERN, desgraciadamente, no podía seguir apoyando el de- 
sarrollo del Web ni al consorcio. 

En cierto modo, era probable que en el interés de todo el mundo 
lo dejasen. El CERN, en el fondo, siempre se había concentrado en la 
física de alta energía, y nunca había desarrollado una gran experiencia 
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con la industria o en una política general para trabajar con ella. Pero a 
mí me parecía que el CERN merecía ser quien se llevase el mérito de 
haberme permitido desarrollar el Web, y por mantener un ambiente 
tan sumamente creativo. La participación constante en el consorcio 
habría cimentado su lugar en la progresiva historia del Web. Yo hu- 
biera preferido ver cómo la organización se llevaba una palmada en la 
espalda que verla desaparecer en la noche. Por su parte Robert segui- 
ría muy implicado con la comunidad web pues seguiría organizando 
la serie de Conferencias WWW anuales. 

El abandono del CERN dejó al consorcio sin una base europea, 
pero había una solución a mano. Yo ya había visitado el Institut Natio- 
nal de Recherche en Informatique et en Automatique (INRIA), el Ins- 
tituto Nacional de Investigaciones Informáticas y Control de Francia, 
en su sede cercana a Versalles. Eran expertos mundialmente reconoci- 
dos en comunicaciones: su sede en Grenoble había desarrollado el na- 
vegador/editor de hipertexto conocido como Grif del que yo había 
estado tan enamorado. Es más, descubrí que Jean-Frangois Abramatic 
y Gilles Kahn, dos directivos de INRIA, entendían perfectamente lo 
que yo necesitaba. Más adelante, a principios de 1996, acordaríamos 
que Vincent Quint e Irene Vatton, que habían seguido desarrollando 
Gif, se unieran al personal del consorcio. Desarrollarían más el soft- 
ware, rebautizado Amaya, que sustituiría a Árena como navega- 
dor/editor estrella del consorcio. 


El torbellino de acontecimientos que habían tenido lugar en sólo se- 
tenta y dos horas fue emocionante pero cansado. El consorcio tenía 
que ponerse en movimiento con una sensación de urgencia si quería 
seguir a la cabeza de las enormes fuerzas que se estaban condensando. 

Tuve que esperar sólo dos meses para que me confírmaran que el 
Web se había convertido en una irresistible fuerza global. En febrero 
de 1995 la reunión anual del G7, las siete naciones más ricas del mun- 
do, se celebró en Bruselas. Los gobiernos del mundo estaban dándose 
cuenta de la influencia que tenía la tecnología y Michael Dertouzos, 
director del LCS, fue invitado a unirse a la delegación de Estados Uni- 
dos. Como Michael describe en su libro What Will Be [Lo que será] el 
conferenciante clave fue Thabo Mbeki, vicepresidente de Sudáfrica. 
Mbeki pronunció un profundo discurso sobre cómo debía la gente 
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enfrentarse a la nueva tecnología para mejorar; para mantenerse infor- 
mados acerca de la verdad de sus circunstancias económicas, políticas 
y culturales; y para darse a sí mismos una voz que todo el mundo pu- 
diera oír. Yo no hubiera podido escribir una declaración mejor sobre 


la misión del World Wide Web. 


9. COMPETITIVIDAD Y CONSENSO 


La historia a menudo da giros dramáticos en hechos que, en el momen- 
to, parecen corrientes. Microsoft quería adquirir los derechos del nave- 
gador de Netscape, comprar acciones de la compañía y establecerse en 
la dirección de Netscape. A su vez Netscape sería el navegador del 
Windows 95 de Microsoft, un sistema operativo completamente nue- 
vo, que lanzaría a Netscape a la enorme industria informática. Pero Jim 
Clark y el nuevo ejecutivo jefe de Netscape, Jim Barksdale, que había 
sido contratado para conseguir dinero y llevar a cabo negociaciones, 
no estaban muy convencidos. La propuesta fracasó y Microsoft redo- 
bló sus esfuerzos para ofrecer su propio navegador. 

Otras negociaciones sí llegaron, sin embargo, a buen puerto, dan- 
do forma poco a poco al competitivo paisaje. En abril, Compaq anun- 
ció que su nueva línea de ordenadores personales vendría con el Na- 
vigator incluido; la primera vez que un navegador acompañaría 
directamente al hardware. 

En mayo, con bastante discreción, Sun Microsystems introdujo 
Java, un nuevo lenguaje de programación. Java era una modificación 
del lenguaje Oak de James Gosling, originalmente diseñado para apa- 
ratos como teléfonos, tostadoras y relojes de muñeca. Pequeños pro- 
gramas de aplicaciones escritos en Java, llamados applets podían ser 
enviados directamente entre ordenadores por Internet y funcionar di- 
rectamente en una pagina web en un navegador. Esa era la teoría. Pero 
resultó que eran necesarias aplicaciones en las cuales una página de hi- 
pertexto no era lo suficientemente interactiva, y hacía falta cierta pro- 
gramación en el cliente. Lo emocionante era que incluso si un ordena- 
dor Á y un ordenador B tenían diferentes sistemas operativos, un 
applet escrito en el ordenador A podría funcionar en el ordenador B, 
porque el lenguaje Java ponía en marcha un ordenador virtual en el 
ordenador B que requería sólo un soporte mínimo del sistema opera- 
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tivo del ordenador B. Sin embargo, muchos lenguajes habían tratado 
de conseguir este objetivo en el pasado, pero el esfuerzo de normalizar 
todas las posibilidades que necesitaban solía ser lo que provocaba su 
fracaso. 

Inicialmente, Java funcionó. De repente, un programador profe- 
sional o aficionado podía crear una aplicación Java, mandarla a un si- 
tio web, y cualquiera en cualquier parte podía descargarla y usarla. 
Java abrió un mundo de posibles aplicaciones web que serían sencillas 
y baratas. Netscape adquirió inmediatamente los derechos de Java y lo 
incorporó a su nueva versión de Navigator. Yo estaba muy emociona- 
do porque Java es un lenguaje orientado hacia los objetos, una técnica 
de programación más potente que la que yo había usado para escribir 
el “World Wide Web”, pero que había abandonado por falta de nor- 
malización. 

En teoría, un ordenador no necesitaría un gran disco duro y mu- 
cha memoria de trabajo (RAM) para almacenar y hacer funcionar vo- 
lúmenes de software para varias aplicaciones como proceso de textos, 
contabilidad, etc. En lugar de ello, un ordenador con un mínimo de 
memoría y RAM podría ir a un sitio web y descargar un applet Java 
para escribir documentos o llevar una contabilidad. Los ordenadores 
personales podían por tanto estar hechos con menos hardware y por 
tanto ser más baratos. Hubo quien pensó incluso que este nuevo desa- 
rrollo podría erosionar el poder de las grandes compañías de softwa- 
re, como Microsoft, ya que los programas más populares de software, 
como los procesadores de texto, podían bajarse de Java en lugar de 
hacerlo en el mercado. Java también significaba que gente con toda 
clase de aparatos de bolsillo, que no podían soportar una gran canti- 
dad de hardware o de software, podían comunicarse y trabajar unos 
con otros por el Web desde cualquier parte. 


Mientras tanto, crecía una gran inquietud entre un grupo de empresas 
tecnológicas que durante varios años habían estado a la cabeza en el 
camino hacia la Era de la Información: los proveedores de servicios en 
línea. CompuServe, Prodigy, America Online y otras que ofrecían 
contenido preempaquetado, como noticias, una enciclopedia, infor- 
mación de viajes y e-mail tendían a representar a Internet como “otra” 
red que era arcana y compleja, algo con lo que no merecía la pena liar- 
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se. Pero de repente el Web hizo que Internet fuera fácil. También hizo 
ver a los suscriptores el hecho de que aquellas compañías en línea eran 
o bien islas aisladas o sólo una pequeña parte de Internet. Para con- 
servar a sus clientes, los proveedores de servicios en línea proporcio- 
naban a regañadientes acceso al Web, aunque seguían tratando de re- 
presentarlo como algo que formaba parte de su reino. A medida que 
aumentaba la cobertura de prensa acerca del Web, los servicios se vol- 
vían más cuidadosos con respecto a no desvirtuar el Web ante un pú- 
blico más inteligente. Tenían que replantearse su postura, presentán- 
dose a sí mismos como proveedores de contenidos organizados y 
seguros, de modo que la gente no tuviera que aventurarse sola por el 
Web para encontrar lo que quería. 

Como parte de la agitación general, America Online (AOL) com- 
pró Navisoft, la empresa que había desarrollado el navegador Navi- 
press que también funcionaba como editor. AOL cambió el nombre 
del producto por el de AOL press. (Es el software que usé yo para ha- 
cer los primeros borradores de este libro.) 

En un determinado momento hubo incluso rumores de que AOL 
estaba tratando de poner en marcha un consorcio como W3C, con un 
nombre similar. Envié un e-mail al director ejecutivo de AOL, Steve 
Case, para tratar de llenar el vacío cultural. Ellos abandonaron la idea, 
dándose cuenta de que todas las compañías web ya formaban parte de 
W3C, y que eran un grupo demasiado grande para que ellos trataran 
de controlarlo, 

Al advertir que Netscape tenía que crecer rápidamente si quería 
competir con los grandes como Microsoft, el director ejecutivo de 
Netscape, Jim Barksdale, decidió que la compañía tenía que hacerse 
pública, para conseguir una buena inyección de dinero. La oferta pú- 
blica inicial (IPO) se hizo el 9 de agosto, sólo dieciséis meses después 
de que se hubiera formado la compañía. Eso era demasiado pronto 
para una IPO, pero Wall Street estaba pagando precios excelentes por 
las acciones de alta tecnología, y Netscape necesitaba munición para 
competir con Windows 95 y el navegador que vendría con el sistema, 
que iba a salir muy pronto, con una gran promoción por parte de Mi- 
crosoft. 

Se iba a lanzar en bolsa con un precio de veintiocho dólares por 
acción, que ya era un precio alto, pero la demanda lo hizo subir rápi- 
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damente a setenta y un dólares. Morgan Stanley, la empresa de inver- 
siones que manejaba la oferta, no podía emitir acciones con la sufi- 
ciente velocidad. Muchas grandes instituciones querían grandes por- 
centajes de propiedad. Siguieron comprando hasta que, al cierre de la 
bolsa, hubo 38 millones de acciones en el mercado. Netscape, después 
de un solo día de venta de acciones, valía 4.400 millones de dólares. 
Era la mayor IPO de la historia, y la compañía aún no había demostra- 
do tener beneficios. 

Si el World Wide Web no había llamado aún del todo la atención 
del público, esta notable historia la sacó al centro de la palestra. Tam- 
bién envió un mensaje inequívoco al mundo comercial: el Web era un 
gran negocio. La fiebre del oro estaba en marcha. El flujo de dinero 
permitió a Netscape comprar pequeñas empresas que habían desarro- 
llado productos especializados para el Web, crear “join ventures” con 
empresas más grandes, y ampliar su línea de productos para apoyar 
grandes contratos con compradores importantes. A finales de 1996, 
cuando fijó su modelo de negocios, Netscape empleaba a más de dos 
mil personas y declaraba beneficios de 346 millones de dólares. Su in- 
flado precio en bolsa bajaría a niveles razonables durante los años si- 
guientes, pero en un solo empujón, el Web se había convertido en un 
importantísimo mercado, 

Después de la IPO de Netscape, la gente empezó a preguntarme si 
estaba molesto porque el Web se hubiera “vuelto comercial”. Aún si- 
guen preguntándomelo hoy día. Una parte de la pregunta quiere de- 
cir: “¿Le importa que la gente tenga que pagar dinero por algunos 
productos web, o al menos por el soporte comercial?”. Por supuesto 
que no. La comunidad del software gratuito era fundamental para el 
desarrollo del Web, y es una fuente de gran creatividad. Pero era ine- 
vitable e importante que si el Web tenía éxito, hubiera una gran varie- 
dad de software tanto gratuito como comercial disponible. 

Un segundo significado de la pregunta se refería al hecho de que 
durante mucho tiempo, se enviaban páginas web por parte de indivi- 
duos y organizaciones no lucrativas, que se relacionaban entre sí sin 
pensar en ganancias. Los académicos que habían usado Internet des- 
de el principio tenían la sensación de que era un espacio abierto, libre 
y puro para su propio uso, y les preocupaba que el generoso espacio 
de información del que habían disfrutado para esos correctos fines se 
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convirtiese ahora en algo inasequible, lleno de correo basura y publi- 
cidad. Ciertas personas pensaban que el material comercial podía 
contaminar el Web. Yo no estaba muy de acuerdo con este punto de 
vista. El Web estaba diseñado como un medio universal. Un vínculo 
de hipertexto tenía que poder apuntar a cualquier cosa. La informa- 
ción que se incluyera con fines comerciales no podía ser excluida. 

La gente me ha preguntado a veces si me preocupa no haber hecho 
mucho dinero con el Web. De hecho, tomé algunas decisiones muy 
conscientes sobre el camino que tomar en la vida. No iba a cambiar 
esas decisiones, aunque no diré lo que voy a hacer en el futuro. Lo que 
sí me molesta, sin embargo, es lo importante que parece ser esa cues- 
tión para algunos. Esto sucede sobre todo en América, no en Europa. 
Lo que es demencial es la noción terrible de que el valor de una perso- 
na depende de lo importante que sea y el éxito financiero que tenga, y 
eso se mide en términos de dinero. Esto supone una falta de respeto 
para los investigadores de todo el mundo que desarrollan ideas para 
los próximos saltos que dé la ciencia y la tecnología. En mi educación 
fue fundamental un sistema de valores que ponía el ganar dinero en su 
justo lugar, detrás de cosas como por ejemplo, hacer lo que realmente 
se quería hacer. Usar las ganancias netas como un criterio por el que 
juzgar a la gente es poner la mirada de nuestros hijos en el dinero en 
lugar de en las cosas que realmente van a hacerles felices. 

A veces puede ser frustrante pensar en las cosas que mi familia po- 
día haber hecho con mucho dinero. Pero en general, estoy encantado 
de dejar que otra gente haga el papel de la familia real (por así decir- 
lo), mientras no abusen del poder que tienen como resultado de ello. 
El consorcio es el foro en el que se encuentra la gente encargada de la 
organización. No es como si yo pudiera tomar decisiones que pudie- 
ran cambiar el Web... pero puedo tratar de conseguir que toda una or- 
ganización industrial lo haga. Mi prioridad es ver el desarrollo del 
Web de un modo que nos mantenga a una buena velocidad durante 
mucho tiempo. Si alguien trata de monopolizar el Web —por ejem- 
plo, impulsando una variación patentada de los protocolos de red— 
se encontrará con la oposición que merece. 


Dos semanas después de la IPO de Netscape, Micrósoft lanzó Win- 
dows 95, y con él el navegador de Windows, Internet Explorer. Bill 
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Gates estaba dando la espalda a su primera estrategia de crear un ser- 
vicio de marcación telefónica, el Microsoft Network, hecho según el 
modelo de AOL. 

- La primera versión del Internet Explorer tenía muy poca funcio- 
nalidad. Yo diría que lo habían puesto en marcha deprisa y corriendo, 
pero hizo avanzar a Microsoft. En diciembre de 1995, Gates hizo lo 
que más tarde se consideraría un famoso discurso a la prensa, en el 
que anunció que su compañía iba a “abarcar y extender” Internet. 
Para algunas personas de la industria informática, “abarcar” significa- 
ba que los productos de Microsoft iban a empezar a ser compatibles 
con el resto del software web, y “extender” significaba que más tarde 
o más temprano, una vez hubieran conseguido su cuota de mercado, 
los productos de Microsoft añadirían características para hacer que 
los sistemas de otros pareciesen incompatibles. Gates estaba haciendo 
funcionar la empresa muy rápidamente y con mucha fuerza para ex- 
plotar enteramente el Web. A la comunidad empresarial le impresio- 
nó que Gates se lo tomase de un modo tan personal. 

Hacia mediados de 1996 millones de personas accedían al Web, 
miles de empresas tenían servidores para él, y la prensa escribía sobre 
él continuamente. Los proveedores de servicios de Internet, ISPs, sur- 
gían por todas partes, ofreciendo acceso al Web por veinte o veinticin- 
co dólares al mes. Informáticos de cualquier pequeña ciudad del mun- 
do empezaron a hacer sus propias páginas y muy pronto se ofrecieron 
a hacer lo mismo para negocios, pequeñas tiendas e individuos par- 
ticulares. 

El consorcio se había colocado en posición de ayudar al Web a 
moverse positivamente hacia delante. Manteníamos reuniones y emi- 
tíamos informes. Pero nuestra directora de comunicaciones, Sally 
Khudairi, se dio cuenta de que íbamos a necesitar algo más que un efi- 
caz sitio web para conseguir transmitir nuestro mensaje. Estableció 
rápidamente relaciones con la prensa y modos de comunicarse con to- 
dos aquellos a los que queríamos informar del trabajo de W3C. Los 
miembros descubrieron de repente toda clase de cosas acerca del con- 
sorcio que nunca habían sabido, y la gente que de verdad necesitaba 
saber las Recomendaciones W3C pero que nunca habían oído hablar 
de nosotros pronto se encontraron usando nuestro nombre como una 
palabra familiar. 
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Al Vezza era un director eficaz y ejecutivo jefe durante los prime- 
ros años; le sustituyó Jean-Francois Abramatic, del INRIA, al que ha- 
bía conocido durante mi primera visita al INRIA. Alan Kotok, que era 
una de las cuatro personas de Digital Equipment que había aparecido 
por mi despacho de Ginebra, acabó siendo del Cornité Asesor, y ahora 
está en el personal como directivo asociado. Dale Dougherty, que de- 
cía “Podemos cambiarlo” en aquel bar de Edimburgo, se uniría más 
tarde a la Junta Asesora, un pequeño grupo seleccionado entre los 
miembros del Comité Asesor. 

El consorcio pronto empezó a desarrollarse y a codificar a su vez 
su proceso para desarrollar futura tecnología y recomendaciones. 
Desde entonces ha seguido evolucionando y refinándose continua- 
mente. Cualquier miembro podía plantear la idea de investigar una 
cuestión. Los miembros o el personal podían hacer un conjunto de in- 
formes, que explicaba por qué era importante tratar de un determina- 
do asunto. Diría cuáles eran las condiciones del mercado, las cuestio- 
nes técnicas, por qué el consorcio debería tratar con esto mejor que 
cualquier otro, cómo podíamos contribuir a una situación, cuál iba a 
ser el siguiente paso —un taller, un grupo de trabajo, varios grupos de 
trabajo— y cuánto nos costaría llevarlo a cabo. 

Se distribuiría un conjunto de informes a todos los miembros. Los 
miembros lo revisarían, haciendo comentarios referentes a su apoyo y 
posible participación. Si había suficiente apoyo y no se planteaban 
problemas graves, creábamos una nueva actividad. Las actividades po- 
dían contener diversos grupos de trabajo, grupos de coordinación, 
grupos de interés, y personal, para conseguir que se hiciera el trabajo 
de una manera abierta, eficaz y de buena calidad. 

Además de tener en cuenta la cuestión técnica fundamental, el 
consorcio tenía que considerar el impacto en la sociedad que se estaba 
construyendo alrededor del Web, y las cuestiones políticas, como por 
ejemplo, si los gobiernos podían hacer cosas precipitadas en el caso de 
que una tecnología no se desarrollara correctamente. Con cada nueva 
actividad, el conjunto de presiones iba a ser diferente. El consorcio 
tendría que ser capaz de responder de un modo muy flexible para 
construir una estructura y una estrategia adecuadas. 

Los grupos de trabajo podían ofrecer sus especificaciones para 
que otros grupos, los miembros y el público las revisaran más amplia- 
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mente. La fase final tenía lugar cuando una solución se convertía en 
Recomendación propuesta, preparada para la revisión formal. A todos 
los miembros se les pediría entonces que hiciesen sus comentarios an- 
tes de treinta días. Entonces se convertiría en una Recomendación 
W3C, se devolvería para que se hiciesen los cambios oportunos, o se 
rechazaría. En teoría, la decisión final sería mía, basada en la informa- 
ción previa (¡igual que los reyes gobiernan, en teoría, en Gran Breta- 
ña!), pero en realidad hacíamos pasar los comentarios de los miem- 
bros por un proceso interno de revisión. En la mayoría de los casos 
solía haber un claro consenso de los miembros. En unos pocos casos 
seguíamos adelante a pesar de las objeciones de una minoría, pero 
sólo tras haber suministrado un detallado análisis de la opinión que 
hubiera prevalecido. Una vez que se daba luz verde a una Recomenda- 
ción, se informaba a los miembros, se entregaba un informe a la pren- 
sa y la máquina de relaciones públicas de Sally animaba a todo el mun- 
do a adoptarla. 

Un día Dan Connolly llegó muy contrariado a la reunión habi- 
tual de los martes del consorcio en el LCS. Yo había conocido a 
Dan hacía tiempo en la conferencia sobre hipertexto en San Anto- 
nio, donde Robert y yo habíamos soldado el módem para poder 
hacer una demostración del Web. Era un tejano pelirrojo que ha- 
bía sido muy activo en Internet y que era un experto en muchos 
temas claves para la tecnología del Web, incluyendo los sistemas 
de hipertexto y lenguajes markup. Se había unido al personal del 
W3C y dirigía nuestro departamento de arquitectura. Aquel día 
llegó diciendo que el proceso de consenso se había roto en un 
grupo de trabajo, y cualquier esperanza de llegar a las fechas topes 
prometidas en otros grupos parecía perdida. Había una compañía 
que se estaba convirtiendo en un gran problema, aunque no podía 
decir por qué razones exactamente. La especificación no iba a sa- 
lir, y el fallo iba a ser un gran golpe para el consorcio y la comuni- 
dad web. 

Dan no quería realmente hablar sobre ello, pero el resto del equi- 
po le llevó de nuevo al tema. Este tipo de problema era el quid del tra- 
bajo. Las cuestiones técnicas podían ser más divertidas, pero esto era 
cosa de construir un consenso, de hacer progresos en una comunidad 
abierta, 
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¿No quería realmente ponerse de acuerdo la compañía problemá- 
tica? ¿No había manera de llegar a un consenso? Cada uno de noso- 
tros interrogó a Dan. Hicimos un diagrama con lo que estaba ocu- 
rriendo en la pizarra blanca. Todo el personal trabajó junto a él en el 
asunto. Al final de la reunión, Dan y el equipo habían desarrollado un 
modo de conseguir que la especificación siguiese adelante. Las com- 
pañías estuvieron de acuerdo al cabo de dos semanas. Me resultó muy 
gratificante ver que el proceso funcionaba incluso en tiempos de con- 
troversia, y significó mucho para mí que el personal pudiese trabajar 
tan bien en equipo. 

Naturalmente, a veces había tensión cuando gente de diversas 
compañías tenía diferentes puntos de vista técnicos sobre cómo esta- 
blecer una recomendación. Á menudo era difícil prever qué represen- 
tante de una compañía iba a hacer el papel del malo o del bueno. Pero 
descubrir una solución técnicamente factible y común era la labor en 
la que estábamos. Ciertamente, el consorcio mejoraba con las tensio- 
nes. Las luchas competitivas por los pedazos de un lucrativo mercado 
proporcionaban ahora el tejido financiero para la revolución tecnoló- 
gica, que a su vez era el tejido de una auténtica revolución de la socie- 
dad. Todo el mundo tenía la necesidad común de ver que la tecnología 
evolucionaba. 


Durante 1996, Netscape lanzó Navigator 2.0, que incluía un e-mail fá- 
cil de usar y aplicaciones Java. Poco a poco, los proveedores de servi- 
cios en línea iban cediendo y proporcionando portales al Web. Bill 
Gates se puso de acuerdo con Steve Case de AOL para proporcionar 
a AOL una versión del navegador Explorer para que los suscriptores 
de AOL que accediesen al Web a través del portal de AOL pudieran 
navegar. Una consecuencia desafortunada de este trato fue, sin embar- 
go, la muerte de AOL press, uno de los pocos navegadores cometrcia- 
les que proporcionaban una sencilla edición en línea. 

La mayor prueba social por la que tuvo que pasar el consorcio lle- 
gó en respuesta a la posible reacción gubernamental frente a la cre- 
ciente preocupación pública por la pornografía en el Web. John Pa- 
trick, de IBM, fue el primer miembro de W3C que habló del tema. 
Sentado a un lado de la pequeña sala del LCS en aquella primera reu- 
nión de veinticinco personas, John mencionó que podía ser un pro- 


106 Tejiendo la Red 


blema que los niños vieran material indecente en el Web. Todos los 
que estaban en la sala se volvieron hacia él con las cejas levantadas: 

“John, el Web está abierto. Esto es un discurso libre. ¿Qué quistes ha- 
cer? ¿Censurarlo?”. 

Detrás de su preocupación se encontraba el hecho de que IBM 
estuviera tratando de instalar ordenadores en aulas escolares de toda 
América, y se estaba encontrando con resistencia porque los padres y 
los profesores estaban preocupados por el acceso a material inade- 
cuado. “Hay que hacer algo”, dijo, “o los niños no podrán tener acce- 
so al Web”. 

Ésta era una preocupación nueva para muchos de nosotros. Deci- 
dimos volver al tema en una reunión posterior, pero entonces la revis-. 
ta Time publicó el artículo de Martin Rimm que decía más o menos 
que una gran proporción de estudiantes pasaba una gran proporción 
de su tiempo navegando en el Web, y que una gran proporción de lo 
que veían era pornografía. 

Aunque esto pudiera ser exagerado, un grupo de empresas se diri- 
gió rápidamente al consorcio pidiendo que se hiciera algo ya, porque 
sabían que el Congreso tenía planes para establecer muy pronto una 
legislación que iba a ser dañina para Internet. Ya había sitios web 
aceptables en Finlandia que horrorizaban a personas de Tennessee, y . 
la idea de que Washington decidiese lo que era “indecente” para todo 
el mundo era ciertamente siniestra. 

Las empresas del consorcio se dieron cuenta de que, como indus- 
tria, tenían que demostrar que podían encontrar una solución. Tenían 
que demostrar que, con una tecnología sencilla, podían dar a los pa- 
dres los medios para controlar lo que estaban viendo sus hijos, y que 
cada padre decidiese lo que consideraba adecuado, y no Washington. 
La idea consistía en crear un sencillo programa que pudiera instalarse 
en cualquier navegador y que permitiera a los padres bloquear los si- 
tios con determinada calificación, como la “R” o la “X” que califican 
determinadas películas. Sin embargo, el programa permitiría a los pa- 
dres escoger las clasificaciones que decidiesen los diferentes grupos 
comerciales, cívicos o incluso gubernamentales. Un servicio de clasifi- 
cación se podría encontrar sencillamente en el URI del grupo. 

El consorcio definiría los lenguajes en los que escribir las clasifica- 
ciones y que las introducirían en el Web. Llamamos a este trabajo la 


Competitividad y consenso 107 


Plataforma para la Selección de Contenidos en Internet (PICS), y la 
lanzamos al público en marzo de 1996. Las compañías miembros in- 
cotporarían esta tecnología a sus productos. 

La legislación que a todo el mundo aterrorizaba era el Acta de De- 
cencia de la Comunicación, que funcionaba en el gran Acta de Teleco- 
municaciones que sin duda iba a aprobarse. Propuesta tanto por el 
partido demócrata como por el republicano, regularía el contenido de 
la Red. Promocionamos rápidamente PICS y varias compañías que te- 
nían miembros en los grupos de trabajo PICS organizaron reuniones 
con la prensa. El Acta de Decencia de la Comunicación se aprobó, 
pero los grupos por los derechos civiles la recurrieron ante los tribu- 
nales. Finalmente, se rechazó como anticonstitucional. La existencia 
de PICS fue un factor importante que contribuyó a que los tribunales 
viesen que el acta no era apropiada, que se podía proporcionar pro- 
tección sin regulación y de una manera que estaba de acuerdo con la 
Declaración de Derechos. 

A continuación se hicieron los esquemas de clasificaciones y vatias 
empresas incorporaron la tecnología. Aparecieron otras empresas que 
se especializaban en software de protección a la infancia. Pero el furor 
se había calmado, la gente se relajó y la industria no llevó más allá la 
tecnología PICS. Aún así, PICS había demostrado que el consorcio 
podía trabajar muy rápidamente, con efectividad y en un nuevo ámbi- 
to: las áreas superpuestas de la tecnología, la sociedad y la política. 


Justo después de que el consorcio pusiera PICS en marcha, yo cometí 
el error de hablar sobre ello con un periodista que no entendía bien el 
principio. Yo pensaba que era bastante sencillo: el W3C desarrolla los 
protocolos, otra parte desarrolla los esquemas de clasificaciones, otras 
partes, como grupos cívicos, emiten las clasificaciones, los protocolos 
se incorporan a productos comerciales y los padres escogen qué es- 
quema de clasificación y niveles quieren usar para bloquear el material 
a cada niño. Combinando esto con las condiciones del código de 
muestra del W3C, el periodista lo convirtió en la declaración de que el 
W3C estaba fabricando un producto para navegar por el Web con se- 
guridad, que sería distribuido gratis a todos los padres, ¡y a finales de 
año! La historia sugería que el W3C estaba socavando el mercado del 
software de protección a la infancia. Aunque el artículo salió en un pe- 
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queño periódico local, aquel periódico pertenecía a una gran compa- 
ñía y, sin yo saberlo, la historia apareció por todas partes, incluso a ni- 
vel internacional. 

- La tarde siguiente, sin saber aún nada del artículo, recibí una lla- 
mada telefónica de Market Wrap, un programa financiero diario de la 
CNBC. Me preguntaban si contestaría a unas cuantas preguntas para 
el programa de la noche. Actuando según la equivocada convicción de 
que toda publicidad es buena, accedí. 

Bajé al sótano de un estudio de televisión local, donde iba a ser fil- 
mado de manera que apareciese en una ventanita de la pantalla del te- 
levisor. Allí me senté, en un cuarto gris sin ventanas, esperando salir al 
aire. Había una cámara que nadie manejaba apuntada hacia mí, y un 
monitor en el que se iba viendo el programa. Mi creciente incomodi- 
dad con la situación llegó al punto álgido de repente cuando oí al pre- 
sentador entrar y decir: “Volveremos en unos minutos con Tim Ber- 
ners-Lee y sus planes para controlar Internet”. 

A partir de ese momento, todo fue a peor. Cuando el presentador 
volvió para empezar la parte en que yo participaba, el monitor se que- 
dó negro. Traté de concentrarme en la voz del presentador en mi oído 
y la cámara que estaba frente a mí, pero sín pistas visuales de lo que es- 
taba pasando. De repente, aparecí. Las primeras palabras del presen- 
tador fueron: “Bien, Tim Berners-Lee, así que realmente inventó us- 
ted el World Wide Web. Díganos exactamente lo rico que es”. 

Era evidente que lo que les interesaba no eran los detalles de la 
PICS. Yo estaba desconcertado. Ellos estaban molestos y luego ansio- 
sos por quitarme de en medio rápidamente a medida que los segundos 
pasaban. Mi debut como cabeza parlante fue un desastre. Desde en- 
tonces, no he estado muy dispuesto a volver a la televisión en directo. 
Al día siguiente, cuando el chapucero artículo se difundió aún más, 
hubo un grito generalizado por parte de las compañías de software di- 
ciendo que estábamos socavando su mercado lanzando (supuesta- 
mente) productos gratis. Tuvimos que emplearnos a fondo para expli- 
car que la historia estaba completamente equivocada. Pero aquello 
fue un gran dolor de cabeza que no necesitábamos. Yo había aprendi- 
do lo difícil que es determinar lo que entiende y lo que no entiende un 
periodista, y lo importante que es que una historia aparezca de mane- 
ra muy clara. También aprendí la verdad fundamental de la vida en el 
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W/3C: nunca sabríamos cuándo iba a ser un día tranquilo o cuándo el 
teléfono no iba a parar de sonar. 


Había más compañías de Japón y de la zona del Pacífico que se esta- 
ban uniendo al consorcio, las suficientes como para que necesitára- 
mos una sede asiática. La Universidad de Keio, en Japón, fue la desig- 
nada, y se convirtió en la tercera institución que sería sede nuestra, 
con el profesor Nobuo Saito como presidente asociado y Tatsuya Ha- 
gino como director asociado para Japón. De pronto, encontrar un 
buen momento para conferencias telefónicas globales se hizo cada vez 
más difícil. 

La industria web estaba creciendo. Las compañías de navegado- 
res, como Netscape, se estaban ampliando y haciendo software para 
servidores, e intranets web para corporaciones. Cientos de grandes 
empresas, desde Chrysler hasta Federal Express, estaban poniendo en 
marcha operaciones web. Productos para trabajar en grupo (group- 
ware) convencionales, como Lotus Notes, que había sido absorbido 
por IBM, fueron reconfigurados de manera que se pudiera acceder a 
ellos con un navegador y usarlos para crear un sitio web.. 

A través del trabajo del consorcio, el HTML se fue haciendo cada 
vez más firme. Hicimos varios primeros trabajos, como el manejo de 
tablas y figuras de Dave Raggett en su navegador Arena, el manejo de 
imágenes insertadas en el texto de Mosaic por parte de Marc Andrees- 
sen, y hojas de estilo para diferentes fuentes y formateos que Hakon 
Lie había liderado desde los primeros días, y que llevó mucho más allá 
de la forma tosca que tenían en mi navegador original en el NeXT, así 
como nuevas innovaciones. A mediados de 1997 los sitios web in- 
cluían habitualmente bonitas fotografías, gráficos animados, informa- 
ción tabular, audio y formularios. El hipertexto lo unía todo dando 
una sensación de multimedia. Aunque era menos visible, el desarrollo 
de mejores servidores estaba avanzando igual de deprisa. 

En otoño, el Internet Explorer de Microsoft había acumulado una 
tercera parte del mercado de navegadores. Pero la compañía hizo que 
se volvieran cabezas cuando empezó a promocionar su nuevo sistema 
operativo, Windows 98, que iba a salir en la primavera de 1998. Según 
Microsoft, esta nueva versión incluiría un navegador mejorado, Ex- 
plorer 4.0. El navegador no sería un programa que viniera junto con el 
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software del sistema, sino que sería una parte integrada del sistema 
operativo, parte integrante del programa que regía el escritorio Win- 
dows, Esto picó la curiosidad del Departamento de Justicia estadouni- 
dense. El Departamento había investigado a Microsoft hacía unos 
años por posible violación de las leyes antimonopolio. Más reciente- 
mente había emitido un decreto de.acuerdo que prohibía la integra- 
ción de productos. ¿Estaba el Explorer 4.0 verdaderamente integrado 
o no era más que un paquete más? 

La fiscal general Janet Reno anunció que el Departamento de Jus- 
ticia llevaría a Microsoft a los tribunales, acusado de violar el decreto. 
Las investigaciones, los requerimientos y las vistas del caso harían que 
este se alargase hasta 1999. 

Fueran cuales fuesen las razones del caso del Departamento de 
Justicia, integrar un navegador en un sistema operativo estaba relacio- 
nado con la conformidad de un interface de usuario para información 
local y remota. Cuando volví de la conferencia Web de Boston en di- 
ciembre de 1995, yo había argumentado que era ridículo que una per- 
sona tuviera dos interfaces diferentes, uno para la información local 
(el escritorio de su propio ordenador) y uno para información remota 
(un navegador para llegar a otros ordenadores). ¿Por qué necesitába- 
mos todo un escritorio para nuestro propio ordenador pero con sólo 
una ventana podíamos ver todo el resto del planeta? ¿Por qué, enton- 
ces, podíamos tener carpetas en nuestro escritorio pero no en el Web? 
Se suponía que el Web era el universo de toda la información accesi- 
ble, que incluía, especialmente, información que resultaba estar alma- 
cenada localmente. Dije que todo el tema acerca de dónde estaba al- 
macenada físicamente la información debía resultarle invisible al 
usuario. Pero esto no tenía que suponer que el sistema operativo y el 
navegador tuvieran que ser el mismo programa. 

El Departamento de Justicia no se preocupaba por los méritos 
del diseño de software. La cuestión era si Microsoft estaba usando 
o no su dominio del mercado para destruir la competitividad. Al in- 
cluir el navegador con Windows 98, decían, la compañía eliminaba 
efectivamente las razones para que cualquiera comprase el Netscape 
Navigator. 

En enero de 1998 Netscape hizo un movimiento sorpresa que re- 
cordaba el carácter original de Internet: en lugar de limitarse a dar el 
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código compilado para su navegador, decía que haría toda la codifica- 
ción fuente —el texto original de los programas tal como lo han escri- 
to los programadores— completamente pública. Esta política de fuen- 
te abierta significaba que cualquiera que promocionase una nueva 
tecnología podía crear su propia versión de Navigator para ella. Eso 
quería decir que cualquier estudiante que estuviera haciendo una in- 
vestigación o sencillamente un proyecto de clase podía crear sus pro- 
pias versiones de partes específicas del navegador, y regenerar el Na- 
vigator con sus propias ideas incluidas. Quería decir que cualquiera 
que estuviera enfadado por un virus de Navigator que Netscape no 
pudiera arreglar, podían arreglarlo ellos mismos, y mandar el arreglo a 
Netscape si querían, para futuras versiones, El lanzamiento abierto 
permitiría a miles de personas mejorar los productos de Netscape. Mi- 
crosoft era más grande que Netscape, pero Netscape esperaba que la 
comunidad web fuese más grande que Microsoft. 


Las historias de Netscape y Microsoft resultaban lectura interesante, 
así que eran el objetivo constante de la prensa. Pero eran sólo una pe- 
queña parte de la historia del Web. Por su naturaleza, el trabajo del 
consorcio era mucho más discreto, pero se centraba en la tecnología 
en evolución. El Web está construido sobre especificaciones técnicas 
y una coordinación fácil de software entre ordenadores, y ninguna ba- 
talla de marketing va a ayudar a ninguna de las causas. 

A finales de 1998 el consorcio había hecho una docena de reco- 
mendaciones. La fortaleza técnica de W3C era mayor. Había más de 
trescientos miembros comerciales y académicos en todo el mundo, in- 
cluyendo vendedores de hardware y software, empresas de telecomu- 
nicaciones, proveedores de contenido, usuarios constituidos en socie- 
dades y entidades académicas y gubernamentales. Las reuniones del 
Comité Asesor se habían trasladado de salas de reuniones a grandes 
auditorios, y las preguntas llegaban de asistentes de pie junto a micró- 
fonos colocados en los pasillos. 

El consorcio había aprendido la manera de permitir que el mundo 
exterior presionase a un miembro que pudiera no estar actuando de 
manera adecuada. Hacíamos recomendaciones —no estándares ni re- 
gulaciones— y no teníamos forma de obligar a nadie a que las acatara. 
Pero los periodistas pueden simplemente escuchar las declaraciones 
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de las compañías acerca de aperturismo y conformidad, y luego com- 
probar su producto más nuevo para ver si la compañía estaba cum- 
pliendo sus promesas. Los vendedores se rigen por los compradores, y 
los compradores se rigen en gran medida por la prensa, que puede in- 
vestigar a cualquiera de quien sospeche que está haciendo trucos. El 
consorcio, la prensa y la comunidad de usuarios funcionan todos 
como parte de un ciclo que ayuda al público a hacer juicios razonables 
acerca de lo honesta que una compañía está siendo con ellos. 

Uno de los principales avances técnicos que tienen que salir del 
consorcio es un lenguaje más simple que sustituya al SGML, llamado 
XML, Lenguaje Markup Extensible. Como el SGML, el XML es una 
base para definir lenguajes como el HTML. Dan Connolly, un arqui- 
tecto web de los primeros días, entendía la tradición SGML. Jon Bo- 
sak venía de una tradición SGML en comités ISO pero veía que el 
Web necesitaba algo más neto. Formaron el núcleo de lo que había 
parecido una esperanza tan remota cuando Dale Dougherty murmu- 
raba: “Podemos cambiarlo” en aquel pub de Edimburgo. 

La revolución XML que siguió fue recibida con gran entusiasmo, 
incluso por la comunidad SGML, ya que mantiene los principios del 
SGML en su lugar. Cuando Tim Bray, editor de la especificación 
XML, la expuso ante los asistentes de la conferencia WWW6 en abril 
de 1997, fue saludado con aplausos. El XML ha seguido adelante 
hasta convertirse en una de las actividades más conocidas de W3C, y 
ha dado origen a libros, conferencias y a una incipiente industria soft- ' 
ware XML. 

El consorcio también desarrolló su propio conjunto de herramien- 
tas web, que usamos para probar la tecnología propuesta a medida 
que llega al grupo. Trata de usar sus recursos limitados para desarro- 
llar al máximo lo que otros aún no se han atrevido a hacer. No pode- 
mos hacerlo siempre, pero tenemos a gente muy buena trabajando 
con nosotros, y buenos vínculos con las principales compañías y uni- 
versidades. 

En 1996 negociamos el derecho del código Grif con INRIA, y lo 
rebatífizamos “Amaya”. Está diseñado totalmente en torno a la idea 
de editar y navegar interactivamente hipertexto, en lugar de procesar 
simplemente HTML primario entrante, de manera que pueda ser 
mostrado en la pantalla del usuario. Amaya puede mostrar un docu- 
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mento, mostrar un mapa de su estructura, permitir editarlo al que lo 
ve, y recuperarlo directamente del servidor web del que procede. Es 
una gran herramienta para desarrollar nuevas características y para 
mostrar cómo las características de diversos programas de edición de 
textos pueden ser combinadas para formar un navegador/editor supe- 
rior, que ayudará a la gente a trabajar junta. Yo me pasé de AOLpress 
a Amaya. 

Un servidor web que usamos es Apache. Cuando el NCSA estaba 
desarrollando Mosaic, me llamaron y me preguntaron si me importa- 
ría que hicieran un servidor. Mi política, naturalmente, era que quería 
que hubiera el máximo de gente posible escribiendo software web, así 
que les dije: “Naturalmente, adelante”. Lo que querían decir, pero no 
dijeron, era que iban a escribir otro servidor que estaría compitiendo 
en “cuota de mercado” con el servidor que había escrito yo. Pero el 
subsiguiente desarrollo del NCSA fue muy lento, así que un grupo de 
personas en todo Internet se unieron para crear “parches” para el ser- 
vidor del NCSA, y el resultado, Apache, se convirtió en servidor por 
derecho propio. Se mantuvo gracias a un grupo distribuido de perso- 
nas en la frontera del desarrollo web, muy al estilo de Internet. Hasta 
el día de hoy, Apache tiene un gran número de usuarios, y es un siste- 
ma de servidor potente y flexible; de nuevo un poderoso testimonio 
de la idea de un software abierto. 

Usamos Apache como nuestro principal servidor accesible al pú- 
blico: usamos nuestro servidor de fuente abierta “Jigsaw” para edi- 
ción en colaboración de todo tipo de documentos, desde Recomenda- 
ciones W3C hasta las actas de nuestras reuniones. Jigsaw es un servidor 
basado en Java, escrito originalmente para el consorcio por Anselm 
Baird-Smith, un mago francés delgado y entusiasta, que puede escri- 
bir código a la velocidad del rayo. Anselm escribió el Jigsaw inicial- 
mente como ejercicio de fondo para que le ayudara a acostumbrarse al 
Java y al HTTP. En los dos meses antes de unirse al consorcio, ya lo 
había reescrito cuatro veces. Jigsaw permite a los miembros y al perso- 
nal leer y escribir documentos de principio al final y al revés, y seguir 
la pista de todos los cambios que se llevan a cabo entre bastidores. El 
Jigsaw tuvo un gran éxito como desarrollo y plataforma de pruebas 
entre los conocedores del Java y el HTTP, por lo flexible que es el ser- 
vidor. 
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En la constitución del consorcio está escrita la estipulación que 
dice que todo el software que produce como apoyo a su trabajo esta- 
rá disponible al público. Es un modo de promocionar recomenda- 
ciones, discusiones y experimentos. Permite a cualquiera unirse a los 
ensayos de nuevos protocolos, y permite a nuevas empresas entrar 
rápidamente en el torbellino de la creación de software web. Lo que 
cualquiera tiene que hacer para ello es ir a la sede del consorcio, 
wiwt0.103.org, y descargar esas herramientas para su uso. 

En el mundo del consorcio entran a veces los temas políticos: in- 
dustriales y gubernamentales. Las compañías hacen en algunas ocasio- 
nes declaraciones técnicas por razones comerciales. Los vendedores 
manipulan los hechos y confunden al público mientras luchan con sus 
competidores. Pero, aparte de todo esto, los miembros del consorcio 
siguen persiguiendo emocionantes avances tecnológicos. Los ingenie- 
ros se desplazan de una compañía a otra, a veces con los proyectos que 
sus jefes abandonan por falta de comprensión, lo que puede ocasionar 
problemas de competencia entre compañías. La telaraña de la vida 
continúa creciendo en toda su plenitud. Y a pesar de las presiones co- 
merciales o las ideas técnicas, los principios del consorcio y las moti- 
vaciones sociales que están detrás, siguen ocupando el centro del esce- 
nario. 


10. UNA RED DE GENTE 


El Web es más una creación social que técnica. Yo lo diseñé por su 
efecto social —para ayudar a que la gente trabajase junta— y no como 
un juguete técnico. El objetivo último del Web es apoyar y mejorar 
nuestra entretejida existencia en el mundo. Nos agrupamos en fami- 
lias, asociaciones y empresas. Tenemos confianza en cosas que están a 
kilómetros y no la tenemos en cosas que están a la vuelta de la esquina. 
Lo que creemos, aprobamos, aceptamos y de lo que dependemos es 
representable y, cada vez más, está representado en el Web. Tenemos 
que asegurar que la sociedad que construimos con el Web es la que 
pretendemos construir. 

Cuando la tecnología evoluciona rápidamente, la sociedad puede 
descubrir que se está quedando atrás, tratando de ponerse al día en te- 
mas éticos, legales y sociales. Esto ha sido el caso sin duda con el 
World Wide Web. 

Las leyes influyen en la manera de interactuar de los individuos, 
con la esperanza de hacer funcionar a la sociedad. Los protocolos defi- 
nen cómo interactúan los ordenadores. Estas dos herramientas son di- 
ferentes. Si las usamos correctamente, los abogados no dirán a los pro- 
gramadores informáticos cómo programar, y los programadores no 
dirán a los legisladores cómo escribir las leyes. Eso es en el caso fácil. 
En el caso difícil, la tecnología y la política se interconectan. El Consor- 
cio Web trata de definir protocolos de manera que no impidan el buen 
funcionamiento de las normas o leyes que gobiernan la interacción de 
las personas. Definimos el mecanismo, no la política. Dicho esto, es 
esencial que política y tecnología se diseñen con un buen entendimien- 
to de las implicaciones mutuas. Como señalé en el cierre de la primera 
Conferencia Internacional World Wide Web en el CERN en mayo de 
1994, los técnicos no pueden limitarse a dejar las cuestiones sociales y 
éticas a otros, porque la tecnología afecta directamente a esas cuestiones. 
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Como el Web es una obra en marcha, el consorcio trata de estable- 
cer un diálogo con los políticos y usuarios acerca de qué tipo de inte- 
racciones sociales debería posibilitar el Web. Nuestro objetivo es ase- 
gurar que el Web integre la mayor diversidad posible de opciones 
políticas públicas. En áreas como la libertad de expresión, la privaci- 
dad, la protección al menor, la propiedad intelectual y otras, los go- 
biernos tienen una función. El tipo de herramientas que ponemos a la 
disposición de todos pueden ayudar a asegurar que esas leyes sean 
efectivas, mientras aseguramos así mismo que los individuos puedan 
conservar un control básico sobre sus experiencias en línea. 

Durante 1996, gran parte de todo lo que ocurrió en el Web se de- 
bió a la excitación que había. Pero en 1998, el Web empezó a ser con- 
siderado como un campo de batalla para los intereses de negocios y 
gubernamentales. Grupos religiosos y de padres empezaron a llamar 
para que se bloquease el material ofensivo que había en el Web, mien- 
tras que los grupos de derechos civiles empezaron a objetar fuerte- 
mente en contra de esas objeciones. Por esta razón, entre otras, mucha 
gente del mundo de los negocios, el gobierno y la sociedad en general 
quería “controlar” el Web de una manera u otra. 

Por desgracia, esos juegos de poder son aquello de lo que más 
oímos hablar en la prensa: el caso antimonopolio del Departamento 
de Justicia contra Microsoft, la fiebre de fusiones y el alza de las accio- 
nes de las compañías de Internet, y la así llamada batalla de los porta- 
les: los intentos de sitios web gigantescos, como Yahoo!, proveedores 
de servicios como America Online, y compañías de contenido como 
Disney por proporcionar la mayor ventana al contenido del Web. 

Mientras que estas maniobras afectan sin duda al negocio del 
Web, en un panorama más amplio son el trasfondo, no el tema princi- 
pal. Algunas compañías crecerán, otras se hundirán, y surgirán nuevas 
de las sombras que sorprenderán a todos. Los éxitos de las empresas y 
los triunfos de las organizaciones no son importantes para nuestro fu- 
turo como usuarios web tanto como las cuestiones fundamentales so- 
ciotécnicas que pueden construir o destruir el Web. Éstas tienen que 
ver con la calidad de la información, las tendencias, los apoyos, la pri- 
vacidad y la confianza: valores fundamentales en la sociedad, muy mal 
entendidos en el Web, y por desgracia altamente susceptibles de ser 
explotados por aquellos que puedan encontrar una vía para ello. 


Una red de gente 117 


Las tendencias en el Web pueden ser insidiosas y llegar muy lejos. 
Pueden romper la independencia que existe entre nuestros proveedo- 
res de hardware, software, opinión e información, corrompiendo a 
nuestra sociedad. Podemos ser capaces de mantener las tendencias a 
raya si todos podemos juzgar el contenido de los sitios web con algu- 
nas definiciones objetivas. Pero el proceso de afirmar la calidad es 
subjetivo, y es un derecho fundamental del que dependen muchas co- 
sas. Se afirma usando sistemas de apoyo, como el protocolo PICS que 
el consorcio desarrolló para mostrar que la censura del gobierno no 
era necesaria. El gran número de herramientas filtrantes de software 
que hay ahora demuestran que la censura del gobierno ni siquiera és 
efectiva: las leyes de una nación no pueden restringir el contenido más 
que en esa nación; los filtros pueden bloquear el contenido de cual- 
quier cosa que llegue por el Web. Más importante aún, los filtros blo- 
quean el contenido a usuarios que ponen objeciones a este contenido 
sin quitar ese material del Web. Sigue estando disponible para aque- 
llos que quieren verlo. 

Me gustaría ver técnicas de apoyo similares usadas para expresar 
otras nociones subjetivas, como calidad académica. 

Lo importante de trabajar en equipo en una red es que funciona- 
mos en grupos: en grupos de dos, de veinte o de veinte millones. Tene- 
mos que aprender cómo hacer esto en el Web. La integridad del pro- 
pio grupo es clave para la existencia de ese grupo, y esa integridad trae 
consigo privacidad y confidencialidad. La privacidad tiene que ver 
con la habilidad de cada persona para dictar lo que puede o no puede 
hacer con su información personal. No hay excusa para que las políti- 
cas de privacidad no sean consensuales, porque escribir, comprobar y 
aceptar esas políticas puede hacerse de manera automática. 

Los acuerdos sobre privacidad son una parte del mayor requisito 
previo de una sociedad en red: la confianza. Tenemos que ser capaces 
de confiar en los miembros de los grupos, en las partes implicadas en 
el comercio electrónico, en el establecimiento que posee una determi- 
nada información, y en mucho más. La diferencia entre el viejo modelo 
informático tipo árbol y el modelo web, más aparente, no está tan pre- 
sente en ninguna parte —ni en ninguna parte está la sociedad tan ata- 
da a la tecnología— como en la estructura en línea que decide qué y 
en quién confíamos. Los criterios que usa una persona para confiar 
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pueden ir desde una creencia heredada de su madre hasta una decla- 
ración hecha por una empresa sobre otra. La libertad de escoger los 
criterios propios de confianza es un derecho tan importante como 
cualquier otro. 

- Una tecnología clave para establecer la confianza es la criptografía 
de clave pública (PKC), un esquema para codificar información para 
que nadie pueda leerla a menos que tenga la clave para decodificarla. 
El modo en que podemos usarla directamente afecta a lo que podemos 
hacer socialmente. Con esta herramienta, podemos mantener conver- 
saciones completamente confidenciales a distancia; confirmar la auten- 
ticidad de los mensajes, comprobar su integridad y responsabilizar a 
sus autores, Sin embargo, no está disponible, en gran parte por razones 
políticas que se explican en el capítulo siguiente. 


Con todo su crecimiento descentralizado, el Web tiene actualmente 
un talón de Aquiles centralizado por medio del cual puede ser hun- 
dido o controlado. Cuando un URI como bttp://www.les.mit.edu/foo 
se usa para encontrar una página web, el cliente comprueba un pre- 
fijo y cuando, como a menudo ocurre, éste es “http”, sabe que 
www.lcs.mit.edu es el “nombre de dominio” de un servidor web. El 
sistema de nombre de dominio funciona en un conjunto jerárquico de 
ordenadores que pueden ser consultados para encontrar la auténtica 
dirección de Internet (uno de esos números como 18.23.189,58) al 
que se pueden enviar los paquetes. En lo alto de la jerarquía hay cinco 
ordenadores que almacenan la lista maestra; y un error de operador en 
uno de ellos apagó una vez todo el sistema, provocando una enorme 
confusión. Esta debilidad técnica es en sí misma menos preocupante 
que la centralización social que la acompaña. 

Tanto los nombres de dominio como las direcciones de Internet se 
dan de un modo delegado. Para establecer el nombre 11. les. 1211. edu, 
uno se registra en el Laboratorio de Ciencias Informáticas, que es el 
propietario del dominio lcs.mit.org. El LCS consiguió su nombre de 
dominio a su vez del MIT, que es el propietario registrado de mit.edu. 
El MIT consiguió su dominio del propietario de edu. El control sobre 
los dominios de “alto nivel” como .com y .edu proporciona indirecta- 
mente control sobre todos los nombres de dominio, de modo que su- 
pone un gran poder. ¿Quién debe ejercer ese poder? 
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Durante la época de crecimiento de Internet, la raíz de una direc- 
ción de Internet era administrada por un organismo conocido como 
Autoridad de Números Asignados de Internet (IANA). El TANA fue 
establecido, dirigido, y básicamente encarnado por el difunto Jon 
Postel, un pionero y gurú de Internet de la Universidad del Sur de Ca- 
lifornia. Jon dirigió el IANA como una empresa pública, neutral. 
Gran parte del crecimiento del Web e Internet dependió de su integri- 
dad como autoridad definitiva que vigilaba que la delegación de nom- 
bres de dominio fuera justa, imparcial y lo más libre de ataduras posi- 
ble. Aquello funcionó debido al tipo de persona que era Jon. El Web e 
Internet como conjunto deben mucho a Jon, que murió en octubre de 
1998 a los cincuenta y cinco años. 

Los posibles problemas sobre el control injusto de los nombres de 
dominio amenazaron con crecer cuando el gobierno de los Estados 
Unidos decidió a finales de 1998 que el IANA debería ser privatiza- 
do. El problema potencial fue exacerbado por aquellos que estaban 
buscando URI. El registro de nombres de dominio siempre se había 
hecho según el criterio de que se servía primero al primero que llega- 
ra. Pero cada vez más todo el mundo se daba cuenta de que los URIs 
cortos y fáciles de recordar eran muy valiosos; la lucha por nombres 
de dominio fácilmente reconocibles, como candy.com y gamble.net al- 
canzaron un punto álgido. Los especuladores empezaron a registrar 
nombres que alguien pudiese valorar en más del precio de registro, 
que era de cien dólares. Nombres de dominio como soap.com y 
sex.com se registraron para poder especular luego con ellos. Algunos 
nombres han cambiado desde entonces de manos por grandes sumas 
de dinero. 

Un problema es que los mejores nombres de dominio irán así a las 
personas o empresas que tengan más dinero, lo que no es justo y ame- 
naza la universalidad. Es más, la posibilidad de cobrar un nombre de 
dominio, que es un recurso escaso e irremplazable, ha dado origen a 
un subcontratista, Network Solutions, que tuvo beneficios, pero no 
tiene la reputación de ser responsable ni de cumplir con sus obligacio- 
nes. Es esencial que los nombres de dominio sean posesión de la gente 
en general, y que sean gobernados de una manera justa y razonable 
por la gente y para la gente. Es importante que no permanezcamos 
ciegos a la necesidad de una autoridad cuando existe la centralización, 
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sólo porque la regla general en Internet sea que la descentralización 
hace que sea innecesario un gobierno central. 

Técnicamente, gran parte del conflicto se debe al desacuerdo en- 
tre la estructura de los nombres de dominio y las reglas del mecanismo 
social que tratan con la propiedad de los nombres: la ley de marcas re- 
gistradas. La ley de marcas registradas asigna mombres corporativos y 
marcas registradas dentro del ámbito del emplazamiento físico de los 
negocios y de los mercados en los que vende. El criterio de la ley de 
marcas registradas de separación según emplazamientos y mercados 
no funciona con los nombres de dominio, porque Internet atraviesa 
todas las fronteras geográficas y no tiene concepto de zona de merca- 
do, y mucho menos una que se ajuste a las convenciones existentes en 
la ley de marcas registradas. Pude haber una empresa de ferretería en 
Bangor, Maine, llamada Joe éx Hijos y un restaurante de pescado lla- 
mado Joe 8 Hijos en San Francisco. Pero sólo puede haber un joeehi- 
jos.com. 

Sea cual sea la solución que se encuentre, ha de ser una solución 
que llene el vacío existente entre la ley y la tecnología, y el abismo es 
bastante amplio. Supongamos que una entidad comercial se limite a 
un solo nombre de dominio. Aunque en esas circunstancias puede ser 
difícil conservar los nombres de dominios cuando las empresas cam- 
bian de manos, se puede evitar que las empresas acaparen nombres 
con cada una de las palabras en inglés relacionadas con su ámbito. 
Hay algunas estratagemas en el sistema existente de nombres de do- 
minio que pueden facilitar el problema. Por ejemplo, si una empresa 
de Boston que fabrique cosas no puede conseguir el nombre de co- 
sas.com porque ya está adjudicado, puede intentarlo añadiendo el 
nombre geográfico: cosas.boston.ma.us. 

La comunidad al completo está poniendo en marcha una organi- 
zación neutral no lucrativa que gobierne el proceso de adjudicar nom- 
bres de dominio. La naturaleza original estadounidense del servicio 
de nombres de dominio ha inquietado a algunas personas no america- 
nas, así que cualquier nuevo organismo tiene que ser demostradamen- 
te internacional. 

Ha habido una propuesta de trabajo para crear nuevos dominios 
de alto nivel: los sufijos .com u .org o «net en los nombres de dominio. 
Esto añadiría dominios de alto nivel para diferentes negocios, como 
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«plastics. De este modo, jones.plastics y jones.electrics podrían ser enti- 
dades distintas, lo que aflojaría un poco la presión. Sin embargo, el 
efecto sería repetir muchas veces la ridícula fiebre del oro que tuvo lu- 
gar con los nombres .com, haciendo necesario que los dueños de ver- 
daderas marcas registradas se tuvieran que proteger a sí mismos de la 
confusión de registrándose no sólo en tres dominios (.cozz, .org y .net), 
sino en muchos más. Á menos que fuese acompañado por un sistema 
legal que justificara la propiedad de un nombre con verosimilitud, un 
esquema semejante haría daño a todo el mundo, excepto a aquellos 
que se encuentran en los márgenes, dispuestos a conseguir dinero rá- 
pido haciéndose con nombres que no van a usar nunca. 

Este es un problema relativamente aislado en el Web, del que el 
W3C ha permanecido prácticamente al margen hasta hoy. Sirve como 
una buena ilustración del modo en que un único punto centralizado 
de dependencia pone trabas a un sistema descentralizado que funcio- 
na bien. También muestra cómo la decisión técnica de que haya un 
solo punto de coordinación puede ser explotado políticamente para 
conseguir poder y comercialmente para conseguir beneficios, destru- 
yendo la independencia de la tecnología con respecto a esas cosas, y 
debilitando el Web en tanto que espacio universal. 

Incluso sin un punto central determinado, el Web puede ser me- 
nos neutral y estar más controlado de lo que pueda parecer. La infra- 
estructura del Web se puede considerar como algo compuesto por 
cuatro capas horizontales; de abajo arriba son los medios de transmi- 
sión, el hardware de ordenador, el software y el contenido. El medio 
de transmisión conecta el hardware en el escritorio de una persona, el 
software hace funcionar el acceso al Web y los sitios web, mientras 
que el propio Web es sólo el contenido informativo que existe gracias 
a las otras tres capas. La independencia de esas capas es importante. 
Desde el punto de vista de la ingeniería de software, éste es el princi- 
pio básico de la modularidad. Desde el punto de vista de la economía, 
es la separación de los mercados horizontales competitivos de la inte- 
gración no competitiva vertical. Desde el punto de vista de la infor- 
mación, piénsese en la independencia editorial, en la neutralidad del 
medio. 

El caso antimonopolio contra Microsoft fue uná gran noticia en 
1999, y en gran parte fue un argumento acerca de la independencia 
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en la capa del software de un sistema operativo y de un navegador. 
Durante ese mismo año, no pasaba un mes sin que hubiera un anuncio 
de fusión o adquisición entre grandes compañías. Se hicieron dos ti- 
pos de negocios: el primero entre compañías que transportaban datos 
por líneas de teléfono y TV, y el segundo entre proveedores de conte- 
nidos. Cada uno de estos negocios estaba teniendo lugar en una de las 
capas del Web. 

Me preocupa más el que las compañías traten de llevarse una taja- 
da vertical de las cuatro capas que el que creen un monopolio en cual- 
quiera de las capas. Un monopolio es más claro; la gente puede verlo y. 
sentirlo, y los consumidores y los reguladores pueden “decir no”. 
Pero la integración vertical, por ejemplo, entre el medio y el contení- 
do, afecta a la calidad de la información, y puede ser más insidiosa. 

Mantener el medio y el contenido separados es una buena regla en 
la mayoría de los medios de comunicación. Cuando pongo la televi- 
sión, no espero que salte deliberadamente a un canal en particular, ni 
que dé una imagen mejor cuando escojo un canal que tenga los anun- 
cios “apropiados”. Espero que mi televisión sea una caja imparcial. 
También espero la misma neutralidad del software. Quiero un navega- 
dor web que me muestre cualquier sitio, no uno que trate de hacerme 
volver sin parar a su sitio base. Cuando le pido a un buscador que en- 
cuentre la información que pueda sobre un tema, no espero que me 
enseñe sólo los sitios de las compañías que hacen publicidad en él o - 
que paguen a la compañía de ese buscador. Si un buscador no me da 
unos resultados completamente neutrales, deberían advertírmelo con 
una nota o un icono. Eso es lo que hacen las revistas cuando incluyen 
un “artículo” que ha pagado un anunciante; tiene un rótulo que pone 
“publicidad” o “sección especial de promociones”, o algo de ese tipo. 
Cuando las compañías de una capa se expanden o fusionan de manera 
que puedan cruzar de una capa a otra, la capacidad de deteriorar la 
calidad de información aumenta en gran manera. 

Los problemas empiezan cuando un programa del que un indivi- 
duo depende para su uso del Web, como un sistema operativo o nave- 
gador, muestra una serie de iconos que automáticamente le conecta- 
rán a buscadores preferidos, sitios web, programas en línea o ISPs. 
Estos arreglos son más problemáticos si un usuario adopta un solo sis- 
tema operativo/navegador que está escrito como un programa de soft- 
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ware integrado, y no puede eliminar esos vínculos o negociar arreglos 
independientes con otros proveedores de servicios similares que pu- 
diesen funcionar con el sistema operativo/navegador. 

Hasta las compañías de hardware están poniendo manos a la obra. 
En 1998, Compaq introdujo un teclado con cuatro teclas especiales: 
pulsando la tecla de Búsqueda el usuario llega directamente al busca- 
dor AltaVista. De pronto, resulta que una persona busca en el Web 
dependiendo de donde ha comprado su ordenador. Un usuario no 
sabe dónde está cuando pulsa la tecla “Buscar en el Web” o “Lo mejor 
del Web” en un navegador o teclado. Esos iconos o teclas llevan al 
usuario a una visión controlada del mundo. Generalmente pueden ser 
dispuestos por el usuario para señalar cualquier buscador, pero pocos 
usuarios cambian el defecto. 

De manera aún más insidiosa, también sería posible que mi ISP 
me conectase mejor con sitios que han pagado para ello, y yo no tengo 
forma de saberlo: puedo creer simplemente que algunas tiendas pare- 
cen tener servidores más lentos. Sería estupendo ver alguna autorre- 
gulación o incluso una regulación gubernamental en esas áreas. 

La universalidad del Web conduce a una creciente riqueza y diver- 
sidad. Si una compañía pretende dar acceso a un mundo de informa- 
ción, y luego presenta una visión filtrada, el Web pierde su credibili- 
dad. Es por eso por lo que el hardware, el software y las compañías de 
transmisión deben permanecer al margen del contenido. Me gustaría 
mantener el conducto al margen del contenido. Me gustaría que siem- 
pre hubiera una opción distinta, cuidadosamente combinada con la li- 
bertad de crear uniones comerciales. Y cuando otras personas están 
haciendo una elección por mí, me gustaría que me lo dejasen total- 
mente claro, 

Algunos pueden decir que esa tendenciosidad entre las capas no 
es más que el mercado libre en acción. Pero si yo compro una radio 
y descubro que sólo puedo oír en ella algunas emisoras y otras no, 
me sentiré molesto. Supongo que podría tener media docena de ra- 
dios, una para cada juego de emisoras. Igual de ridículo es tener me- 
dia docena de ordenadores o diferentes sistemas operativos o nave- 
gadores para acceder al Web. Esto no es sólo poco práctico, sino 
que fragmenta el Web, haciendo que deje de ser universal. Yo ten- 
dría que poder comprar cualquier ordenador, software y servicio de 
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transmisión que quisiera y seguir teniendo acceso al contenido ente- 
ro del Web. 

Los portales representan el crecimiento reforzado de los monopo- 
lios, especialmente de aquellos que se integran verticalmente. En su 
contexto más amplio, la batalla de los portales es una batalla por nom- 
bres de marca en el Web. Es difícil para la gente juzgar la calidad de la 
información, o el software web o los servicios, sin una gran experien- 
cia y posibilidad de comparación. Como resultado, el software o las 
empresas de transmisión con reputaciones ya establecidas pueden ca- 
pitalizar el uso de sus nombres para atraer a personas a sus servicios 
de información. El caso extremo sería una compañía que ofreciese 
transmisión, hardware, software e información y luego pretendiera ser 
más o menos equivalente al Web. También sería una repetición del 
servicio de marcación de AOL y CompusServe que existían antes del 
Web, a una mayor escala. De momento, la prisa por dominar ha con- 
ducido hacia arriba la calidad del Web, pero si una compañía consi- 
gue ese dominio, destruiría el Web tal como lo conocemos. 

Felizmente, el Web es tan enorme que no hay modo de que ningu- 
na compañía pueda dominarla. Todo el esfuerzo que la gente y las or- 
ganizaciones de todo el mundo han hecho para crear sitios web y pági- 
nas iniciales es asombrosamente grande, y la mayor parte de ese 
esfuerzo tiene que ver con lo que está en el Web, no con el software 
que se usa para navegar en él. El contenido del Web, y por tanto su va- 
lor, continuará a pesar de las acciones de cualquier compañía en con- 
creto. 

Pero consideremos lo que podría ocurrir dentro de un año o dos 
cuando los buscadores mejoren. Cliqueo en el botón de Búsqueda de 
mi teclado, o digo a un buscador: “Quiero comprar un par de zapa- 
tos”. Supuestamente el buscador se lanza al Web para encontrar tien- 
das de zapatos, pero de hecho me trae sólo las tiendas de zapatos que 
tienen un acuerdo con ese buscador o compañía de hardware. Lo mis- 
mo con librerías. Y compañías de seguros. Y noticias. Y así sucesiva- 
mente. Mi selección de tiendas y servicios ha sido así limitada por la 
compañía que vende el ordenador o dirige el buscador. Es como tener 
un coche con un botón que dice “Ir a comprar zapatos” en el salpica- 
dero; cuando lo apretamos, nos lleva sólo a la tienda de zapatos que 
tiene un acuerdo con el fabricante del coche. Eso no me ayuda a con- 
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seguir el mejor par de zapatos por el mínimo precio, no contribuye al 
mercado libre ni contribuye a la democracia. 


Mientras haya incentivos comerciales para integrar verticalmente las 
capas en un negocio, la responsabilidad legal puede complicar el pa- 
norama. En 1998, un tribunal bávaro condenó a Felix Somm, un anti- 
guo director de la división alemana de CompuServe, por complicidad 
en difundir deliberadamente pornografía vía Internet. La sentencia 
suspendida de dos años señaló la primera vez en Alemania que el jefe 
de una compañía en línea fuera responsabilizado de proporcionar ac- 
ceso a un contenido considerado ilegal. El material se obtenía de or- 
denadores de otros países, pero a través de la puerta de CompuServe a 
Internet. Cuando la frontera entre el medio y el contenido se desdibu- 
ja, cada ISP o compañía de telecomunicaciones se encuentra en peli- 
gro de ser considerada responsable del contenido. 

Somm dijo que había notificado a las autoridades alemanas acerca 
del material ilegal y que incluso les había ayudado en sus investigacio- 
nes. CompuServe proporcionó también a sus suscriptores software 
que podían usar para bloquear el contenido indecente. Somm puede 
tener la oportunidad de ser absuelto según una nueva ley alemana refe- 
rente a los multimedia que se promulgó después de que fuera condena- 
do. Esta ley dice que los proveedores de Internet pueden ser responsa- 
bilizados del material ilegal de sus servidores sólo si son conscientes de 
ello, si es técnicamente posible detenerlo y no toman medidas razona- 
bles para bloquear el acceso a él; que es lo que Somm y CompuServe 
dijeron que habían hecho. Los abogados defensores de Somm argu- 
mentaron que nadie podía saber todo lo que había en Internet, y que 
bloquear el acceso a cualquier parte es un ejercicio fútil. 

Ya que el Web es universal y libre, hay toda clase de basuras en 
ella. Como padres, tenemos el deber de proteger a nuestros hijos pe- 
queños para que no vean materiales que puedan dañarles psicológica- 
mente. Filtrar el software puede cribar la información bajo control del 
lector, evitar al lector la molestia de tener que leer lo que considera ba- 
sura. La gente usa filtros en el correo electrónico para clasificar auto- 
máticamente la información entrante. Una persona tiene sin duda el 
derecho de filtrar cualquier cosa que le llegue, igual que haría con el 
correo normal: abre algunas cartas y otras las tira a la papelera. Sin ese 
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derecho, el día a día sería un caos. En el futuro, los buenos navegado- 
res podrán ayudar al usuario a evitar los vínculos a sitios web que ten- 
gan características que él les haya indicado que no le interesan, ya sea 
la presencia de palabras malsonantes o el hecho de que ese sitio con- 
tenga anuncios. 

Pero cuando alguien impone filtros involuntarios a otro, eso es 
censura. Si se supone que una biblioteca proporciona un ordenador 
que da a los ciudadanos acceso a Internet, pero evita el acceso a cierto 
típo de material, como pornografía, entonces la biblioteca está deci- 
diendo por la gente lo que deberían poder leer. La biblioteca se estaría 
erigiendo en autoridad central que sabe mejor que el lector lo que él 
quiere. 

En 1998 clientes de la biblioteca pública de Loudon County, Vir- 
ginia, pusieron una demanda para quitar un programa filtro instalado 
en los ordenadores de Internet en seis sucursales de la biblioteca. De- 
cían que, mientras que el filtro les impedía acceder a sitios pornográfi- 
cos, también les bloqueaba el acceso a sitios de educación sexual, cán- 
cer de mama y derechos de los gays y lesbianas. Aquí el principio es 
más interesante que las discusiones de detalles: el pleito decidió que la 
política de la biblioteca era una forma de censura gubernamental in- 
constitucional. 

Un caso ilustra lo espinosas que pueden resultar estas decisiones 
cualitativas: un caso de 1998 descrito en el New York Times. “La Aso- - 
ciación de Familias Americanas, un grupo cristiano conservador, ha 
apoyado los productos filtrantes. Así que con cierta sorpresa, inte- 
grantes del grupo descubrieron recientemente que un filtro muy po- 
pular llamado Cyber Patrol estaba agrupando sus propias páginas 
web junto con los sitios de supremacía blanca y otros sitios que pro- 
pugnaban la intolerancia. Investigadores de Cyber Patrol decidieron 
que el sitio se ajustaba a las definiciones de intolerancia del filtro, que 
incluye la discriminación basada en la orientación sexual.” Parece ser 
que los investigadores encontraron declaraciones en las páginas del 
grupo que hablaban en contra de la homosexualidad. Cyber Patrol re- 
chaza doce categorías de material que considera inapropiado para los 
niños de doce años, desde las apuestas hasta los sitios de cultos. 

La naturaleza subjetiva de estas decisiones es la razón por la cual 
establecimos el sistema PICS para permitir a cualquiera que escogiese 
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lo que quisiera sin imponer nada a los demás. La clave de los PICS y 
de cualquier intento de filtrado, es proporcionar control al lector, y 
poner a la disposición de los diferentes grupos diferentes filtros. Con 
PICS, los padres no están limitados a un proveedor dado, o incluso a 
un sistema dado de clasificaciones. Tienen un súrtido de programas 
de vigilancia comerciales a su disposición para poder escoger, una se- 
lección en la que confiamos. 

Lo más importante que hay que recordar es que las leyes deben es- 
cribirse en relación con las acciones, no con la tecnología. Las leyes 
existentes que hablan de los aspectos ilegales de la información son 
suficientes. Las actividades como el fraude y la pornografía infantil 
son ilegales en línea y en la vida real. No me gusta la idea de que al- 
guien controle el tipo de información a la que puedo acceder. Creo, 
sin embargo, que un padre tiene que proteger a sus hijos en Internet, 
igual que vigila a dónde van físicamente. Pero la decisión de la infor- 
mación a la que los adultos pueden acceder o no es cosa suya. 

Este principio era la esencia de las disputas de la Primera Enmien- 
da sobre la constitucionalidad de las leyes de censura de Internet. 
Cuando el primer esfuerzo que se hizo por censurar Internet fue a los 
tribunales, los miembros del consorcio pensaron que era importante 
que los tribunales entendieran cómo pueden actuar los filtros como 
alternativa eficaz a la censura. Proporcionamos información básica 
durante las deliberaciones. En 1996, el Tribunal Supremo de Estados 
Unidos rechazó la ley de censura, en parte porque los filtros permiten 
a los padres proteger a sus hijos sin necesidad de que el gobierno in- 
tervenga y haga de niñera. Pero en 1998, el Congreso propuso otra ley 
de censura. Está siendo recurrida de nuevo, con lo que este tema está 
lejos de haber quedado resuelto. 

El debate también se ha complicado. Algunos grupos a favor de 
los derechos civiles argumentan que los gobiernos represivos podrían 
usar programas como el PICS para acallar comunicados sociales o po- 
líticos en el Web que el gobierno no quisiera que se leyesen. Un grupo, 
el Global Internet Liberty Campaign (GILC), escribió una carta 
abierta al Consorcio Web diciendo que, para evitar ese peligro, el 
W3C no debería emitir Reglas PICS. Las Reglas PICS son una parte de 
la tecnología PICS que permite a una persona o grupo almacenar sus 
preferencias en un disquete, y dárselos a otra persona para que lo use. 


t 


128 Tejiendo la Red 


AI GILC le preocupaba que el software necesario para hacer esto pu- 
diera ser mal utilizado por parte de gobiernos represivos contra su 
propio pueblo. Al GILC también le preocupaba, según Amy Harman, 
del New York Times, que si la tecnología PICS se difundiera amplia- 
mente, el Congreso pudiéra aprobar una ley que exigiera a los padres 
adoptar unas Reglas PICS determinadas. Como esto constituiría un. 
control por parte del gobierno, el GILC decía que el consorcio no de- 
bería hacer que las Reglas PICS fuesen un estándar. Deberíamos ente- 
rratlas. 

Aquí los liberales parecen querer influenciar a la tecnología a fin 
de constreñir al gobierno. Me parece preocupante cuando los ameri- 
canos de cualquier partido no se fían de su sistema político y tratan 
de dar vueltas en lugar de ir derechos. El consorcio no va a evitar 
malas leyes controlando selectivamente qué tecnología desarrolla y 
cuándo la va a lanzar. Los técnicos tienen que actuar como miem- 
bros responsables de la sociedad, pero no tienen por qué meterse a 
gobernar el mundo. El consorcio hace eso deliberadamente. Trata 
de evitar el actuar como un registro central, un beneficiario central, 
o un establecedor de valores central. Proporciona los mecanismos 
técnicos, no las políticas sociales. Y así es como vamos a seguir fun- 
cionando. 


La condición abierta del Web también supone que los modelos em- 

presariales deben ser un tema importante. Las compañías relaciona- 

das con el comercio electrónico son muy conscientes de ello, y algunas 

están intentando evitar posibles imposiciones gubernamentales de 
modelos éticos tratando de regularse a sí mismas, sobre todo por me- 

dio de avales o respaldos. 

El Netcheck Commerce Bureau, por ejemplo, es un sitio donde las 
compañías pueden registrar su compromiso con determinados mode- 
los de conducta, y recibir el respaldo correspondiente. Los clientes 
pueden hacer reclamaciones contra dichas compañías en Netcheck. 
El U.S. Better Business Bureau, que existe hace mucho tiempo, tiene 
un sitio web que proporciona herramientas similares. Idealmente, las 
reclamaciones hechas en esos sitios serían revisadas de modo que si 
una compañía no se comporta bien con sus clientes, perdería el sello 
de aprobación. 
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Algunas grandes compañías se están preocupando por establecer 
qué es en esencia un marchamo de calidad. Como el tema fundamen- 
tal es determinar en qué sitio se puede confiar, si alguien pone su con- 
fianza en una gran empresa como IBM, e IBM determina que otras 
empresas son éticas, entonces la persona también confiará en esa com- 
pañía. Ciertamente, IBM ha desarrollado lo que llama una 7zarca e-bu- 
síness, que concede a empresas que ha hecho negocios y que han de- 
mostrado un compromiso al proporcionar un medio seguro y fiable 
para los negocios electrónicos. Es como el símbolo del Underwriters 
Laboratory, o el Sello de Aprobación de Good Housekeeping. 

Contrariamente a las regulaciones, los respaldos los puede pro- 
porcionar cualquiera, acerca de cualquier cosa, según cualquier crite- 
rio. Esta independencia de tres vías convierte a los sistemas de respal- 
do en algo muy abierto. Un individuo puede confiar en un producto, 
en alguien que lo respalde o en un determinado criterio de respaldo. 

La autorregulación funciona cuando hay libertad para establecer 
diferentes modelos, y el cliente tiene libertad para escoger. Sin embar- 
go, si la “autorregulación” se convierte simplemente en una versión 
industrial del gobierno, regida por los grandes negocios y no por el 
electorado, perdemos la diversidad y conseguimos un sistema menos 
democrático. 

La marca e-business puede ser un precursor del modo en que se 
llevarán a cabo muchos avales. La gente en general no podrá saber si 
pueden confiar o no en una determinada tienda en línea. Así que se 
decantarán por marcas “fiables”; o aquellas respaldadas por éstas. 

PICS era el mecanismo del consorcio para permitir que los avales 
se codificaran y se comprobaran automáticamente. Inicialmente se 
pretendía mostrar que un sitio web cumplía ciertos criterios porque 
en ellos no había desnudos, violencia, etc. No se ha implantado am- 
pliamente porque no hay el suficiente incentivo económico para que 
la gente clasifique los sitios. Pero puede haber un gran incentivo cuan- 
do se trate de proteger la privacidad de los datos personales que al- 
guien da a una tienda de ropa en línea. La cuestión es en qué clasifica- 
ciones confiar. 

Como consumidor, me gustaría que me informasen de los avales 
que ha recibido un sitio, pero sin que me distrajeran del contenido. 
Quizá podrían aparecer iconos en una ventana que dejase abierta 
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mientras accedo a un sitio, o en el borde de la página que estoy vien- 
do. Se pueden proporcionar avales en todos los campos, no sólo en 
el de los negocios. Puede haber avales académicos: cuando hojeo in- 
formes de investigación buscando enfermedades del corazón, puede 
aparecer un aval que diga que determinado informe se ha publicado 
en un reputado periódico. Cada lector irá a los periódicos en los que 
confíe. Un individuo haría lo mismo con avales de asociaciones de su 
profesión. Y si su asociación médica, por ejemplo, ignora una rama 
particular de medicina alternativa en la que él cree, entonces puede 
usar un aval que esté basado en un periódico determinado sobre me- 
dicina alternativa. Ésa es la belleza del Web; es una red, no una je- 
rarquía. 


Los respaldos o avales como modo de transmitir juicios de calidad 
funcionan fácilmente en el Web, porque pueden hacerse por medio 
de vínculos de hipertexto. Sin embargo, por muy importante que sea 
esta facilidad, es incluso más importante entender que un vínculo no 
tiene por qué suponer un respaldo. El discurso libre en hipertexto su- 
pone el “derecho a vincular”, que es la unidad básica constructiva de 
todo el Web. 

En el hipertexto, los vínculos normales se hacen entre un docu- : 
mento de hipertexto y otro documento externo. Los vínculos ¿ncor- 
porados son aquellos que hacen que algo aparezca junto con un do- 
cumento; aparece una imagen en una página web porque hay un 
vínculo incorporado entre la página y la imagen. Los vínculos nor- 
males de hipertexto no suponen que el documento vinculado forme 
parte, esté respaldado o relacionado en propiedad con el primer do- 
cumento. Esto es así a menos que el lenguaje usado para identificar 
el contenido del documento vinculado contenga algún significado en 
ese sentido. Si el creador del primer documento escribe: “Ver página 
web de Ered [vínculo], que es guay”, esto es claramente un respaldo. 
Si escribe: “Damos más detalles en nuestro folleto de venta [víncu- 
lo]”, se supone que la autoría es la misma. Si escribe: “El mensaje 
[vínculo] de Fred está escrito maliciosamente y es una mentira to- 
tal”, está denigrando (probablemente de manera calumniosa) el do- 
cumento vinculado. Clarificar el estatus relativo de un documento 
vinculado es a menudo útil para los lectores, pero la persona tiene 
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que ser responsable acerca de lo que dice, igual que lo haría en cual- 
quier medio. 

En el caso de los vínculos respaldados, el autor del documento tie- 
ne responsabilidad, incluso si el contenido ha sido importado de otro 
sitio web, y hasta si el documento da el URI para el texto o imagen 
respaldados para que un navegador pueda comprobar la fuente origi- 
nal. Si yo escribo acerca del crecimiento del Web y muestro un gráfi- 
co, el gráfico es parte de mi documento. Es razonable esperar que yo 
me responsabilice de la imagen igual que del texto. Son lógicamente 
parte del mismo documento. La publicidad respaldada en un sitio es 
la excepción. Sería estupendo que el HTML distinguiera vínculos a 
documentos “extraños” con vínculos a documentos con autoría co- 
mún, y que los navegadores pasaran esta información a los usuarios de 
la misma manera. 

Pero más allá de esta distinción entre vínculos normales y respal- 
dados, persisten aún ciertos malentendidos. He aquí tres mitos que 
se han colado en la “sabiduría popular” del Web, y mi opinión acerca 
del modo en que los protocolos de hipertexto deberían ser interpre- 
tados, 


MITO UNO. “Un vínculo normal es una incitación a copiar el docu- 
mento vinculado de un modo que infringe el copyright.” La capaci- 
dad para referirse a un documento (o a una persona, o a cualquier 
cosa) es un derecho fundamental del libre discurso. Hacer una refe- 
rencia con un vínculo de hipertexto es eficaz, pero no cambia ninguna 
otra Cosa. 

De todos modos, en septiembre de 1998, ABC News contó la his- 
toria de un fotógrafo que trató de demandar a los grandes almacenes 
JC Penny, que tenían un vínculo desde su sitio con el sitio Movie Data- 
base LT'D., que a su vez tenía un vínculo con un sitio web de la Swedish 
University Network, de quien se decía que había copiado ilegalmente 
una imagen del fotógrafo. Por fortuna, la demanda se desestimó. Una 
buena regla por defecto es que la legalidad en línea es la misma que 
fuera de línea. Los usuarios, los proveedores de información y los abo- 
gados tienen que alcanzar un consenso sobre esto. De otro modo, la 
gente tendrá miedo a crear vínculos a causa de las posibles implicacio- 
nes legales. Pronto sería imposible hasta hablar de las cosas. 
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MITO DOS. “Crear un vínculo con un documento externo da más 
valor al primer documento, y por tanto es algo por lo que se debe pa- 
gar.” Es cierto que un documento adquiere más valor gracias a los vín- 
culos que tenga con ciertos documentos relevantes y de gran calidad, 
pero eso no significa que nada pertenezca a la gente que creó esos do- 
cumentos. En cualquier caso, deberían alegrarse de que más gente pu- 
diera referirse a ellos. Si alguien en una reunión me recomienda como 
un buen contacto, ¿espera esa persona que yo le pague por hablar de 
mí? Lo dudo. 


MITO TRES. “Crear un vínculo con un documento públicamente le- 
gible de alguien es infringir la privacidad.” Los servidores web pue- 
den proporcionar modos de dar acceso a sitios web sólo a personas 
autorizadas. Esta tecnología debería usarse, y los servicios de acogida 
de los sitios web deberían dar a los que publican documentos un con- 
trol sobre el acceso. “Seguridad por medio de la oscuridad” —escoger 
un extraño URI y no decírselo a nadie— no es algo convencional, y 
por tanto debe hacerse un acuerdo muy explícito con cualquiera a 
quien se le dé el URI. Una vez que algo se haya hecho público, nadie ' 
se puede quejar de que su dirección haya circulado. 

Yo creo que está bien tener protección para informaciones confi- 
dencíales que se hayan hecho públicas accidentalmente, por acción 
ilegal o por obligación legal, como un mandato judicial. La suposición 
de que una vez que la información ha escapado “accidentalmente”, se 
puede usar libremente, es desafortunada. 

Éstas son mis opiniones personales acerca de cómo debería inter- 
pretarse el hipertexto, y mi propósito. No soy experto en los temas le- 
gales de cada país. Sin embargo, si el derecho general a vincularse no 
está apoyado por cualquier razón, entonces los principios fundamen- 
tales del discurso libre están en entredicho, y sería mejor que algo 
cambiara. 


11. PRIVACIDAD 


Cuando el Web empezó a funcionar, una de las cosas que le impedía 
desarrollarse era a menudo la reticencia de la gente a abrirse en rela- 
ción a sus obras: sus fuentes y las razones que había detrás de esas 
obras. A mí eso me parecía frustrante, y abanderé un movimiento a 
favor de la apertura de la información mientras promocionaba el 
Web como un modo de fomentar esa apertura. Sin embargo, rápida- 
mente separé las dos cosas, ya que el Web no presupone, ni debe ha- 
cerlo, la idea de que toda la información deba siempre compartirse. 
Para mantener la integridad, un grupo necesita una frontera respeta- 
da, que en el Web es una frontera de flujo de información. Los gru- 
pos tienen que poder hablar entre sí, y tener sus propios datos cuan- 
do sea necesario. 

Quizás la mayor preocupación acerca de la privacidad por parte 
de los consumidores sea la de que, después de que se les haya encarga- 
do unos cuantos productos, las compañías habrán acumulado sufi- 
ciente información personal para dañarles o aprovecharse de ellos. 
Las consecuencias pueden ir desde la amenaza del correo basura hasta 
la negativa a que alguien les haga un seguro sanitario, y el problema es 
serio. El Web tiene dos aspectos que pueden causar aún más preocu- 
pación. Uno es que la información puede recogerse mucho más fácil- 
mente, y el otro es que puede usarse muy fácilmente para adaptar lo 
que una persona experimenta. 

Para ver lo que podía pasar con mi información personal, busqué 
el modo en que algunos proveedores en línea han usado mi dirección. 
Cuando doy mi dirección a un sitio web, pongo en ella una cosa falsa, 
como un número de apartamento, por ejemplo. Su ordenador lo re- 
gurgita palabra por palabra, de modo que yo puedo averiguar, cuando 
más tarde recibo cotreo basura, quién les ha proporcionado mi di- 
rección. 
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Hay más cosas amenazadorás. Los ladrones pueden encontrar 
muy útil saber quién ha comprado qué últimamente. Más probable es 
el tipo de abuso que tiene lugar cuando un médico divulga el estado 
médico de alguien a la compañía aseguradora para justificar una recla- 
mación. Dos años más tarde, la compañía aseguradora saca la infor- 
mación de sus bases de datos cuando un futuzo empleador quiera co- 
nocer esos informes. La persona no consigue el trabajo por culpa de 
una antigua enfermedad y nunca llega a saber qué ocurrió. 

El software puede incluso encontrar el esquema de clics que hace 
una persona en un sitio web. Si un usuario abre una revista en línea, 
los editores pueden comprobar qué artículos lee, qué fotografías bus- 
ca y en qué orden, y extraer información acerca de él que él nunca ad- 
mitiría en un formulario. Esto se llama información “click stream” 
[seguimiento de clicks]. Net Perceptions, puesta en marcha por un 
antiguo directivo del departamento de lenguajes de programación de 
Microsoft, es una empresa que hace software que las compañías pue- 
den usar para controlar todo tipo de comportamientos en línea, desde 
la cantidad de tiempo que un visitante pasa leyendo acerca de un pro- 
ducto determinado, hasta qué páginas imprime en su impresora. 

Si un anunciante publica anuncios en diferentes sitios y descubre 
el “click stream” de una persona hacia una determinada selección de 
sitios, puede construir un perfil bastante exacto de los sitios que esa 
persona visita. Esta información puede venderse a casas de venta di- 
recta, o a quien sea. Una famosa viñeta de los principios de la época de 
Internet muestra a dos perros sentados ante un ordenador. Uno le ex- 
plica al otro: “Lo bueno de Internet es que nadie sabe que eres un pe- 
rro”. Hace poco salió otra viñeta en la que un perro ha cliqueado en 
una página con una foto de comida para perros, Á causa de esto, el 
servidor ahora sabe que es un perro. Muy pronto el servidor sabrá 
también que es un perro que prefiere una determinada marca de co- 
mida para perros, los olmos y los gatos siameses. 

En el diseño básico del Web, cada vez que alguien hace clic en un 
vínculo, su navegador va de servidor en servidor de nuevo, sin refe- 
rencias a transacciones previas. La controvertida herramienta para lo- 
calizar al consumidor que lo cambia todo es la cookíe. Una cookie no 
es más que un código, como un número de referencia o un número de 
cuenta que el servidor asigna al navegador para reconocerlo cuando la 
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misma persona vuelve. Es muy parecido a cuando a una persona le 
dan un número cuando abre una cuenta en el banco. La cookie se al- 
macena automáticamente en el disco duro del consumidor, con o sin 
su conocimiento, dependiendo de sus preferencias. 

La mayoría de las transacciones entre un consumidor y una tienda 
suponen una cierta continuidad, y la cookie permite acumular cosas 
en un carrito de la compra, o manda cosas a la misma dirección de la 
última vez. Normalmente, los comerciantes con los que tratamos sa- 
ben lo que hemos comprado, qué banco tenemos y dónde vivimos, y 
nosotros confiamos en ellos. El hecho de que las cookies se suelan ins- 
talar en el disco duro de una persona y respondan al servidor, sin nin- 
guna clase de permiso, también es valiosa: es la diferencia entre ir a 
una tienda y ser reconocido como persona digna de crédito, o ir y te- 
ner que rellenar todos los formularios de identificación cada vez. 

Sin embargo, hay quien considera a las cookies como algo malva- 
do. Por defecto, la mayoría de los navegadores aceptan todas las coo- 
kies automáticamente, pero también la mayoría ofrecen al usuario la 
opción de advertirle con una nota de aviso antes de que el ordenador 
acepte una cookie, o sencillamente rechazarla. El problema no está en 
la cookie, sobre la que el usuario tiene control, El problema es que no 
se sabe qué información recogerá el servidor, y cómo la utilizará. Sin 
esa información el usuario puede hacer elecciones basadas sólo en el 
miedo y la duda; no es una base estable para construir una sociedad en 
el Web. 

Un sitio web también puede cambiar como un camaleón según 
quién esté-visitándolo, como si fuera un folleto impreso para esa per- 
sona únicamente. Imaginemos a un individuo visitando la página web 
de un candidato político, o de una compañía controvertida. Con una 
rápida comprobación del dossier de esa persona, el político o la com- 
pañía puede datle la mezcla adecuada de propaganda que gustará a 
esa persona; y suprimirá con tacto los puntos a los que pueda poner 
objeciones. ¿Es esto sólo marketing dirigido, o engaño? Depende de 
si sabemos que está ocurriendo o no. 

Europa ha intentado resolver parte de este problema con una te- 
gulación estricta. Las compañías europeas tienen que mantener a sal- 
vo la información que poseen sobre sus clientes, y no pueden combi- 
nar bases de datos de una manera que es legal en Estados Unidos. Los 
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consumidores europeos también tienen derecho a mirar y corregir las 
bases de datos que contienen información acerca de ellos. En Estados 
Unidos, las leyes que protegen a los consumidores contra la venta o 
entrega de sus datos son muy débiles. El gobierno espera que se esta- 
blezca algún tipo de autorregulación. 

La buena noticia es que el Web puede ayudar. Creo que la privaci- 
dad que requiero de la información que doy es algo que debería poder 
elegir. La gente debería poder navegar por el Web anónimamente, o 
como una entidad bien definida, y debería poder controlar la diferen- 
cia entre las dos cosas. Me gustaría poder decidir a quién voy a permi- 
tir usar mi información personal y para qué. : 

Actualmente, un sitio web responsable tendrá una política de pri- 
vacidad a la que se podrá acceder con un clic en la parte de abajo de la 
página de inicio. Un sitio puede vender cualquier información que re- 
coja a firmas de correo directo o publicidad. Otra podrá grabar cual- 
quier página que vea un visitante. Otra podrá no distribuir ninguna 
información bajo ninguna circunstancia. Yo podré leer esto atenta- 
mente y decidir si sigo o no, pero en la práctica, no suelo tener tiempo 
de leerlo antes de precipitarme en la página. 

El siguiente paso es permitir a mi navegador que haga eso por mí; 
no sólo comprobar, sino negociar una política de privacidad diferente, 
una política que sea la base de cualquier emisión posterior de infor- 
mación. Con software de privacidad, un proveedor de sitios web y un 
navegador pueden hacer eso precisamente. 

Pensemos en una compañía que vende ropa por Internet. Puede 
declarar su política de privacidad de la siguiente manera: “Cogemos 
su nombre, edad, y sexo para dar forma a las páginas de nuestro catá- 
logo según el tipo de ropa en el que probablemente esté interesado y 
para nuestro propio desarrollo del producto. No proporcionaremos 
esta información a nadie de fuera de nuestra organización. También 
recogemos información sobre el lugar al que se lo enviaremos. Pode- 
mos distribuir esta información a otros”. 

Para que estas cosas se negocien automáticamente, las preferen- 
cias establecidas por un usuario y la política de privacidad tienen que 
ser fijadas de una forma legible por la máquina usando una serie co- 
mún de categorías para diferentes tipos de datos y diferentes formas 
de usarlos. 
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El Consorcio World Wide Web está creando una tecnología que 
permitirá la negociación automática entre el navegador de un usuario 
y el servidor de una tienda, lo que conducirá a un acuerdo sobre priva- 
cidad, El Proyecto de Plataforma por las Preferencias en Privacidad 
(P3P) darán a un ordenador la posibilidad de describir las preferen- 
cias de privacidad y las exigencias del propietario del ordenador, y 
dará a los servidores un modo de describir sus políticas de privacidad, 
hecho todo de modo que las máquinas puedan entenderse entre sí y 
negociar cualquier diferencia sin que haya una persona a cada extre- 
mo diciendo lo que hay que hacer. 

Creo que cuando un sitio no tiene política de privacidad, debería 
haber una política de privacidad por defecto obligatoria por ley que 
proteja al individuo, Quizá esta opinión demuestre mis raíces europeas. 
Y puede parecer contraria a mis tendencias normalmente minimalis- 
tas. Pero la falta de dicha obligación permite a una compañía hacer lo 
que quiera con cualquier dato privado que pueda extraer. 

En 1998, la Federal Trade Comission hizo una investigación de si- 
tios web y descubrió que muy pocos tenían una política de privacidad, 
incluyendo sitios que pedían información a niños. Los descubrimien- 
tos fueron tan dramáticos que el presidente Clinton convocó una reu- 
nión de dos días sobre privacidad en Internet en Washington con la 
industria y el gobierno. Los resultados impulsaron también a la Fede- 
ral Trade Comission a pensar en regular las políticas de privacidad. 

Como suele ser a menudo el caso, la posibilidad de una regulación 
ha impulsado a la industria a hacer algunos movimientos hacia la auto- 
rregulación. En junio de 1998, Christine Varney, una antigua comisa- 
ría de la FTC, reunió a un grupo de unas cincuenta compañías y gru- 
pos de comercio llamado Online Privacy Alliance [Alianza de 
Privacidad En Línea]. Entre sus miembros estaban AOL, AT8zT, Mi- 
crosoft, Netscape, la Asociación de Marketing Directo y la Cámara de 
Comercio estadounidense. Dijeron que revelarían claramente cual- 
quier información que recogiesen en todos sus sitios web, y el modo 
en que iba a ser usada. También dijeron que darían a los consumido- 
res opciones acerca de cómo podían usarse los datos personales, in- 
cluyendo la posibilidad de no permitir que su información se vendiese 
a terceras partes. El Better Business Bureau Online [Oficina para Me- 
jorar los Negocios en Línea] también está manejando el asunto con un 
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servicio de respaldos, un sello de privacidad que concede a sitios web 
interesantes. El programa muestra el establecimiento de criterios de 
privacidad, verificación, comprobación y revisión de reclamaciones. 

Algunos reguladores mantienen que como no hay mecanismo al- 
guno para que esto sea obligatorio, este tipo de esfuerzo no va lo sufi- 
cientemente lejos. Un control más estrecho es necesario, dicen, espe- 
cialmente cuando se trata de proteger información sobre niños. 
Mantienen que cualquier abuso de información acerca de adultos o de 
niños debe ser ilegal. Pero la Online Privacy Alliance es un buen prin- 
cipio, al menos para crear un sistema de respaldos, lo que hará que 
más consumidores graviten en torno a los sitios que se adhieran. Esto 
animará a los demás a hacer lo mismo. Idealmente, esos grupos esta- 
blecerán prácticas de privacidad que serán automáticamente compro- 
bables en el P3P. 

Naturalmente, cualquier negociación sobre privacidad es sólo tan 
digna de confianza como lo sea el propietario del sitio. Sin embargo, si 
una compañía se ha comprometido, por medio de su servidor web, a 
preservar la privacidad, y ha roto este compromiso, entonces ha actua- 
do fraudulentamente. Hay leyes convencionales que manejan este tipo 
de transgresiones. El software no puede resolver el problema. Y no 
debería ser cosa del consorcio ni de ningún organismo técnico el re- 
solverlos. 

Quizás la violación más notoria de la privacidad en el Web fue el 
repentino lanzamiento a finales de 1998 de detalles sobre el informe 
del Consejo Independiente de Estados Unidos sobre las actividades se- 
xuales del presidente Clinton. Esta información fue expuesta delibera- 
damente ante millones de personas, contrariando las opiniones de mu- 
cha gente acerca del respeto al individuo o a la familia. Podemos usar el 
poder del Web para conectar cualquier cosa con cualquier otra para 
provocar un golpe de efecto, o para hacer daños devastadores. Episo- 
dios como éste nos ayudan a reconocer lo rápidamente que la distribu- 
ción de la información puede perjudicar a nuestra sociedad —y a cada 
uno de nosotros personalmente— si absolutamente toda la informa- 
ción se hace pública. 


Nadie va a tomar parte en la nueva forma de trabajar en red si no nos 
sentimos seguros de que la información privada seguirá siendo priva- 
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da. En un grupo, también permaneceremos apartados si tenemos la 
sensación de que lo que se dice o se escribe no es confidencial, o si no 
podemos asegurarnos de con quién nos estamos comunicando. 

La criptografía de clave pública (PKC) ofrece un modo de conse- 
guir cuatro aspectos básicos de seguridad: autenticidad, confidenciali- 
dad, integridad de mensajes y honorabilidad. Cada persona tiene un 
número que todo el mundo conoce (la clave pública), y otro número 
relacionado con el anterior que no tiene nadie más (la clave privada). 
Concebida hace más de dos décadas, la PKC proporciona una forma 
de encriptación en la que un mensaje saliente es codificado según la 
clave pública del receptor. El mensaje interferido sólo puede decodifi- 
carlo un receptor que tenga la única clave privada adecuada para 
abrirlo. Una forma líder de criptografía de clave pública es la RSA, 
cuyo nombre proviene de sus creadores, Ron Rivest, Adi Shamir y Le- 
onard Adleman, que pertenecían todos al Laboratorio de Ciencias In- 
formáticas del MIT en 1977 cuando la inventaron. 

Deducir si alguien o un lugar son auténticos es cuestión de sentido 
común. Si un sitio web ofrece un trato que parece demasiado bueno 
para ser cierto, probablemente es que así es. Es más difícil, sin embar- 
go, descubrir si el sitio web de una tienda de ropa muy conocida lo 
está realmente controlando esa tienda. Cualquiera puede crear un si- 
tio que parezca una tienda de ropa. Los estafadores podrían tener in- 
cluso un elaborado sitio falso que acepte un encargo, lo pase a la ver- 
dadera tienda, mande de vuelta la comunicación de la tienda y 
mientras tanto robe el número de la tarjeta de crédito. Y contraria- 
mente a una fachada física, la tienda falsa no podrá distinguirse de la 
real. Actualmente hay intentos de hacer más seguro el sistema de 
nombres de dominio, pero llega un momento en que la autenticidad 
depende principalmente de la seguridad contra la intrusión de los ser- 
vidores de dominio (que dicen al navegador dónde está en Internet, 
por ejemplo, w1w01w.acme.com) y las conexiones entre ellos. La autenti- 
ficación de clave pública sería mucho mejor. 

La confidencialidad consiste en saber que nadie más puede acce- 
der al contenido de una comunicación. De nuevo, delincuentes o es- 
pías pueden interceptar una comunicación hecha a una tienda de ropa 
y robar números de tarjetas de crédito que se envían electrónicamen- 
te, o meterse en una conversación supuestamente privada entre varias 
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personas de un grupo. La tecnología de encriptación evita esto pertur- 
bando los mensajes. Cualquiera que navegue en un sitio cuyo URI em- 
piece por https: está usando una tecnología de encriptación llamada 
Secure Sockets Layer. Normalmente, sin embargo, la criptografía se 
usa sólo para asegurarse de que nadie excepto el servidor pueda leer la 
comunicación, no para verificar que el servidor es realmente quien 
dice que és. | 

La integridad de los mensajes lleva consigo implícito el hecho de 
asegurarse que nadie pueda alterar un mensaje en Internet sin que sea 
detectado, y la falta de honorabilidad significa que si yo he enviado un 
mensaje, no puedo mantener más tarde que no lo he hecho. La PKC 
proporciona tecnología para asegurar también esto. Si uso el software 
para aumentar un mensaje que envío (o una página web que escribo), 
un número al final llamado f2rma digital permite al receptor verificar 
que he sido yo el que lo mandó y que no ha sido manipulado. El con- 
sorcio proyecta añadir firmas digitales a los documentos. 

Si la PKC se entiende tan bien, ¿por qué no la usamos? Una de las 
razones es el miedo del gobierno a la pérdida del control. Es fácil de 
usar y prácticamente imposible de falsear; tan imposible, de hecho, 
que desde que se desarrolló, hace más de veinte años el gobierno esta- 
dounidense ha bloqueado la exportación de criptografía fuerte clasifi- 
cándola como “munición”. Algnos otros gobiernos han reaccionado 
de igual forma, bloqueando la exportación, o prohibiendo su uso, por 
temor a que los grupos terroristas puedan comunicarse sin que el go- 
bierno sea capaz de intervenir sus conversaciones. 

El argumento en contra apunta a la visión de George Orwell en su 
libro 1984, en el que la Agencia de Seguridad Nacional se convierte en 
el Gran Hermano, capaz de vigilar el más mínimo movimiento de una 
persona. Señala el hecho de que sin el derecho básico del ciudadano a 
hablar de lo que quiera, la gente queda a merced de potenciales ten- 
dencias dictatoriales por parte del gobierno. 

El equilibrio del poder gubernamental es siempre complicado. 
Pero el debate es casi discutible en este caso, porque la tecnología de 
encriptación ha sido escrita en muchos países del mundo libre. La le- 
gislación sobre exportación de Estados Unidos frustra los deseos de la 
gente que quiere simplemente, por ejemplo, comprar ropa en otro 
país. Enfurece a los fabricantes de software que tienen que hacer dos 
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versiones de cada producto, uno con una fuerte PKC y el otro con una 
versión específicamente debilitada para la exportación, y luego idear 
modos para tratar de evitar que la fuerte cruce las fronteras. Obstacu- 
liza la comunidad de la Fuente Abierta, en la que la distribución del 
código fuente (forma escrita original) de los programas es un princi- 
pio básico. Para ridiculizar la ley de exportación, los programas de 
PKC se han impreso en camisetas, y en fuentes legibles por medio de 
aparatos en libros; artículos estos que no están sujetos a controles de 
exportación. 

Hay otra razón por la cual no se ha adoptado la PKC: puede ser 
usada sólo junto con un sistema que diga a nuestro ordenador en qué 
claves públicas confiar para según qué clase de cosas. Esto es, natural- 
mente, algo muy importante pero muy difícil de expresar. La capaci- 
dad que pueda tener un individuo para expresar confianza es esencial, 
porque sin esa confianza, muchos de los usos del Web, desde el traba- 
jo en colaboración hasta el comercio electrónico, serían socialmente 
imposibles. 

La autenticidad y la confidencialidad no son problemas nuevos 
para el Web. Han sido resueltos, en principio, para el correo electró- 
nico. Pretty Good Privacy [Privacidad Bastante Buena] (PGP) y Se- 
cure MIME son dos estándares para firmar correo digitalmente (para 
autentificar a la persona que lo manda) y encriptarlo (para evitar que 
nadie más lo lea). 

El PGP es más o menos un sistema fundamental. Es un web de 
confianza. Otra alternativa, Public Key Infrastructure [Infraestructura 
de Clave Pública] (PKT) es básicamente una manera con estructura de 
tipo árbol de hacer las cosas. En el PGP o el PKI el ordenador de un 
usuario asocia una clave con una persona por medio de un archivo ]la- 
mado certificado. Suele llevar el nombre de la persona, sus coordena- 
das y la clave pública. El certificado está firmado digitalmente con 
otra clave pública de otra persona en quien el usuario confía. Sabe que 
es la clave de la otra persona porque lo dice en un certificado que fue 
firmado con la clave de una persona diferente en la que confía. Y así 
sucesivamente, formando una cadena. 

La estructura social que tiene el PGP consiste en que las cadenas 
de confianza puedan hacerse por medio de cualquiera; la familia, los 
amigos, la universidad o los jefes de una persona. Si un individuo 
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fuese a autentificar un mensaje de un colega, probablemente usaría 
un certificado firmado por su jefe común. Ése es el camino de la con- 
fianza. 

El sistema PKTI, concebido por la industria para permitir el comer- 
cio electrónico, asume que la gente confía sólo en unas cuantas “raí- 
ces” básicas de las que emana toda autoridad. Unas pocas autoridades 
delegan el derecho de emitir certificados en sus socios comerciales. 
Estos a su vez pueden delegar el derecho de emitir certificados en 
otras autoridades menores. Hay una estructura tipo árbol, y el dinero 
y la autoridad fluyen arriba y abajo por ella. 

Los navegadores están siendo equipados poco a poco actualmente 
para que puedan funcionar con la PKT. Si abro los favoritos del nave- 
gador en mi Internet Explorer ahora, veo que puedo elegir aceptar 
certificados firmados por Microsoft, ATT, GTE, MCI, Keywitness 
Canada Inc., Thawte y Verisign. En la lista equivalente de Netscape, 
veo ATT, BBN, BelSign, Canada Post, Certisign, GTE, GTIS, IBM, 
Integrion, Keywitness, MCI Mall, Thawte, Uptime y Verisign. Todas 
esas autoridades certificadas responderán por la identidad de las per- 
sonas y sus claves. Generalmente mandan certificados que expiran 
tras un número determinado de meses. Pero no veo un botón que me 
permita emitir un certificado para un amigo o pariente en el que tam- 
bién confío. El PGP debería permitir hacerlo. 

El Web funcionó debido a que la habilidad de cualquiera para crear 
un vínculo le permitía representar información y relaciones tal como 
existían en la vida real. La razón por la que la criptografía no se usa 
constantemente para representar la confianza en el Web es porque 
aún no es una infraestructura con forma de red, descentralizada. 


El sistema PGP se basaba en el correo electrónico y asumía que 
cualquiera conservase copias de los certificados en sus discos duros. 
No había vínculos de hipertexto que permitieran a cualquiera seña- 
lar un certificado en el Web. Claramente, debería ser mucho más fá- 
cil introducir un Web de Confianza determinado dada la estructura 
del Web. 

Mencioné que tanto el PGP como la PKI presuponían dos cosas: 
que nos fiábamos de una persona, y que, si lo hacíamos, no teníamos 
más que vincular a esa persona con una clave. Ha habido muchas dis- 
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cusiones inútiles y puntos muertos acerca de qué es lo que constituye 
una persona, y cómo establecer la identidad de una persona. De he- 
cho, en la mayoría de las situaciones no importa quién “es” la persona 
de un modo único y fundamental. Un individuo sólo está interesado 
en el papel que la persona juega, lo que está representado por una cla- 
ve pública. Lo único que tenemos que hacer es encontrar un lenguaje 
para hablar acerca de lo que se puede hacer con diferentes claves, y 
tendremos una infraestructura técnica para un Web de Confianza. Si 
jugamos bien nuestras cartas, el trabajo del consorcio referente a los 
lenguajes en el Web (que describiré en el capítulo 13) acabarán dando 
lugar a un Web de Confianza. Entonces el Web y el Web de Confianza 
serán lo mismo: una red de documentos, algunos firmados digital- 
mente, vinculados y completamente descentralizados. El consorcio no 
trata de tener un papel principal ni controlador en el Web de Confian- 
za; Sólo ayudará a la comunidad a crear un lenguaje común para ex- 
presar la confianza. 

El Web de Confianza es un modelo esencial para el modo en que 
realmente queremos trabajar en tanto que personas. Cada uno de no- 
sotros construye nuestra propia red de confianza a medida que vamos 
madurando a partir de la infancia. Cuando decidimos a qué nos va- 
mos a vincular, qué vamos a leer o qué vamos a comprar en el Web, 
uno de los elementos de nuestra decisión es hasta qué punto confia- 
mos en la información que estamos viendo. ¿Podemos confiar en el 
nombre del editor, en los métodos de privacidad, en las motivaciones 
políticas? A veces aprendemos en qué no debemos confiar del modo 
más duro, pero más a menudo heredamos la confianza de otro —un 
amigo, un maestro o un miembro de la familia—, o de publicaciones 
recomendadas, o avales de terceras partes, como nuestro banco o 
nuestro médico. El resultado de toda esta actividad crea una red de 
confianza en nuestra parte de la sociedad. 

Los sistemas automatizados surgirán de manera que las negocia- 
ciones y transacciones puedan basarse en nuestro criterio de confian- 
za establecido. Una vez que tengamos esas herramientas, podremos 
pedir al ordenador no sólo información, sino también por qué hemos 
de creerle. Imaginemos un botón que ponga “Ah ¿sí?” en nuestro na- 
vegador. Aquí estoy, buscando un negocio fantástico que puede ser 
mío sólo con introducir el número de mi tarjeta de crédito y el clic de 
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un botón. Aprieto el botón “Ah, ¿sí?”. Mi navegador requiere del ser- 
vidor que le proporcione credenciales. Quizá sea una lista de docu- 
mentos con respaldos firmados digitalmente, por ejemplo, por el ban- 
co o el proveedor de la empresa, con las claves para verificarlos, Mi 
navegador rebusca entre ellos con el servidor, tratando de convencer- 
se de que el negocio es de fiar. Si se siente satisfecho, mejor para mí, he 
conseguido un buen negocio. Si no, probablemente me habré ahorra- 
do unos cuantos quebraderos de cabeza. 

Sería una equivocación suponer que el Web de Confianza es im-- 
portante sobre todo para el comercio electrónico, como si la seguri- 
dad sólo importase en lo que al dinero se refiere. El Web tiene que so- 
portar todo tipo de relaciones, a todos los niveles, desde el personal, a 
través de grupos de todos los tamaños, hasta la población global. 
Cuando estamos trabajando en grupo, compartimos cosas que no 
compartiríamos fuera de ese grupo, como ideas a medio hacer o infor- 
mación delicada. Lo hacemos porque nos fiamos de las personas del 
grupo, y confiamos en que no divulgarán esta información a otros. 
Hasta ahora, ha sido difícil conseguir formar ese tipo de grupo en el 
Web, porque es difícil controlar el acceso a la información. El Web de 
Confianza puede servir como medio de auténtica colaboración. Tiene 
que estar ahí antes de que confiemos en agentes automatizados que 
nos ayuden en nuestro trabajo. Estos desarrollos, de los que hablaré 
en los dos capítulos siguientes, son para mí los más importantes del 
Web como conjunto. 


12. MENTE A MENTE 


Tengo un sueño acerca del Web... y ese sueño tiene dos partes. 

En la primera parte, el Web se convierte en un medio mucho más 
potente de colaboración entre las personas. Siempre he imaginado el 
espacio de la información como algo a lo que todo el mundo tuviera 
acceso inmediato e intuitivo, y no sólo para navegar, sino para crear. 
El programa inicial World Wide Web apareció con una página casi va- 
cía, lista para las anotaciones del usuario. Robert Caíilliau y yo lo pasa- 
mos muy bien con él, no porque estuviéramos viendo muchas cosas, 
sino porque estábamos escribiendo y compartiendo nuestras ideas. Es 
más, el sueño de la comunicación entre personas a través de conoci- 
mientos compartidos debería ser posible en grupos de todos los tama- 
ños, que interactuasen electrónicamente con tanta facilidad como lo 
hacen ahora en persona. 

En la segunda parte del sueño, la colaboración se extiende a los 
ordenadores. Las máquinas se vuelven capaces de analizar todos los 
datos que hay en el Web: el contenido, los vínculos y las transacciones 
entre personas y ordenadores. Un “Web semántico” que debería ha- 
cer eso posible, aún está por aparecer, pero cuando lo haga, los meca- 
nismos diarios del comercio, la burocracia y nuestra vida diaria serán 
manejados por máquinas que hablen con máquinas, dejando a los se- 
res humanos que aporten la inspiración y la intuición. Los “agentes” 
inteligentes que la gente ha anhelado siempre se materializarán final- 
mente. Este Web comprensible a través de las máquinas llegará gra- 
cias a la implantación de una serie de avances técnicos y acuerdos so- 
ciales que están empezando a aparecer ahora (y que describiré en el 
próximo capítulo). 

Una vez que se llegue a cumplir el doble sueño, el Web será un lu- 
gar en el que el deseo de un ser humano y el razonamiento de una má- 
quina coexistan en una mezcla ideal y potente. 
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Realizar el sueño requerirá mucho trabajo meticuloso. El Web está 
lejos de estar “completo”. Sólo está en sus comienzos, y por muy gran- 
dioso que sea el sueño, tendrá que ser construido pieza por pieza, y 
muchas de estas piezas estarán lejos de ser atractivas. 

Es mucho más fácil imaginar y entender un Web más poderoso y 
culto si rompemos con muchas de las ideas actuales acerca de cómo 
usamos los ordenadores, Cuando yo quiero interactuar con un orde- 
nador, tengo que esperar varios minutos tras encenderlo hasta que 
esté listo para funcionar. Esto es absurdo. Se supone que estas máqui- 
nas tienen que ser para nosotros, no al revés. Así que empecemos a 
imaginar un nuevo mundo imaginando uno en que haya una pantalla 
de ordenador disponible en el lugar que queramos. 

Siguiendo con el mismo modo de pensar, deberíamos deshacernos 
de todas nuestras ideas preconcebidas acerca del acceso a Internet. 
¿Por qué hemos de esperar mientras el ordenador conecta con Inter- 
net a través de una llamada de teléfono? Internet no está diseñado 
para esto. Está hecho de modo que, en cualquier momento, un peque- 
ño paquete semejante a una postal de unos cientos de caracteres pue- 
da dejarse caer en un ordenador, y en una fracción de segundo estar 
en su destino al otro lado del mundo. Por eso cuando cliqueamos en 
un icono podemos ir rápidamente a un sitio web. La molestia de tener 
que hacer una llamada de teléfono destruye la idea de la disponibili- 
dad inmediata. 

Un objetivo esencial para la industria de las telecomunicaciones (y 
las autoridades reguladoras) debería ser el conectar a todo el mundo 
con un acceso permanente. El problema hasta ahora no ha sido la tec- 
nología, sino más bien las regulaciones que controlan lo que las com- 
pañías telefónicas pueden cobrar por el acceso, y la falta de acuerdo 
acerca de cómo otras compañías que pueden querer proporcionar ac- 
ceso a Internet puedan alquilar el cable de cobre que llega a cada casa. 
Con regulaciones un poco más razonables, en algunos casos fomenta- 
das por la competitividad entre las compañías de cable que llevan sus 
propios cables hasta la puerta de la gente, antes de no mucho tiempo 
deberíamos poder llegar a una pantalla, ver cómo brilla rápidamente 
con nuestra página de inicio, y establecer inmediatamente un vínculo. 
Esta simple diferencia de tiempo cambiará espectacularmente el modo 
en que usamos los ordenadores, haciendo que la experiencia sea más 
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parecida a sacar una pluma que a sacar la cortadora de césped. Los or- 
denadores se encontrarán a nuestra disposición cuando tengamos una 
idea, permitiéndonos capturarla y evitar que el mundo se la pierda. 

Clarifiquemos nuestras mentes acerca de lo que veremos en esos 
maravillosos nuevos ordenadores. Hoy día hay ún escritorio con va- 
rias carpetas y “aplicaciones”. Una de esas aplicaciones es un navega- 
dor web. Según este esquema, mi pantalla entera es utilizada por mi 
ordenador local, mientras que toda la información en el resto del 
mundo accesible es relegada a una pequeña zona o icono en su inte- 
rior, Esto está al revés. 

La labor de los ordenadores y las redes consiste en quitarse de en 
medio, no en ser vistos. Esto significa que la aparición de la informa- 
ción y las herramientas que se usan para acceder deberían ser inde- 
pendientes del lugar en donde se almacena la información; el concep- 
to de independencia de localización. Ya sean páginas de hipertexto o 
carpetas, ambas maneras válidas de manejar la información, deberían 
tener el mismo aspecto fuera donde fuese que se encontrasen física- 
mente. Los nombres de archivos deberían desaparecer; deberían con- 
vertirse simplemente en otra forma de URI. Luego la gente debería 
dejar de ver los URIs, viendo sólo los vínculos de hipertexto. La tecno- 
logía debería ser transparente, para que pudiéramos interactuar con 
ella intuitivamente. . 

El siguiente paso sería la independencia de protocolo. Ahora mis- 
mo, cada vez que escribo algo en un ordenador, tengo que escoger si 
abrir la aplicación de “correo electrónico”, la aplicación de “noticias 
en red” o la aplicación del “editor web”. El correo, las noticias y los 
sistemas web usan diferentes protocolos entre ordenadores, y efecti- 
vamente, me piden seleccionar qué protocolo usar. El ordenador de- 
bería averiguar esto él solo. 

La independencia de localización y la independencia de protocolo 
serían muy sencillas si todo el software de un ordenador se volviera a 
escribir desde cero. Por desgracia, no es así. El cambio necesario para 
el diseño modular de los sistemas operativos y aplicaciones tendría 
que ser significativo. Ciertamente, si los términos sistema operativo y 
aplicaciones sobrevivirán o no, no está claro. Pero como los ingenieros 
de software son muy imaginativos, y las apuestas —un interface intui- 
tivo— están altas, soy optimista. 
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Al observar el modo en que una persona usa el Web, vemos que es 
más sencillo mejorar la recepción de información añadiendo nuevas 
formas de gráficos y multimedia. Es más difícil imaginar cuál es la me- 
jor manera de permitir a una persona interactuar con la información, 
crearla y modificarla. Más difícil aún es imaginar cómo su pantalla de 
ordenador puede usarse para permitir que una persona interactúe 
como una de muchas personas interactuando como grupo. Éste es el 
orden en que el desarrollo ha tenido lugar hasta la fecha, y seguirá te- 
niendo lugar en el futuro. 

La revolución XML, mencionada en el capítulo 9, que ha tenido 
lugar durante los últimos años y está llegando ahora a la corriénte prin- 
cipal, ha proporcionado unos sólidos cimientos a una gran parte del 
nuevo diseño dentro y fuera del consorcio. Incluso aunque los lengua- 
jes de markup de ordenador para hipertexto y gráficos estén diseñados 
para presentar texto e imágenes a la gente, y los lenguajes de datos es- 
tán diseñados para ser procesados por máquinas, ambos comparten la 
necesidad de un formato común y estructurado. Eso es el XML. 

El XML es tanto una ventaja como una amenaza para el sueño del 
Web. Lo grande es que detiene la corriente de la pérdida de informa- 
ción. Permite que cualquiera cree cualquier tipo de etiqueta que cap- 
ture la intención de un fragmento de información. Por ejemplo, las ac- 
tas de una reunión pueden contener un “tema de acción”. El XML 
permite a la persona que toma nota de las actas el hacer un nuevo do- 
cumento tipo que incluya <acción>. Si las actas se están registrando en 
HTML, esto puede perderse, porque el juego general de etiquetas de 
HTML no incluye <acción> y la persona que escribe las actas no pue- 
de crear una. Un documento XML es más completo: la información 
que contiene está mejor definida. 

Esto permitirá cosas como hojas de cálculo, archivos de calenda- 
rio, libretas de direcciones e-mail, y resúmenes bancarios que no ha- 
yan usado formatos estándar interoperables para que se desarrollaran 
rápidamente, lo que aumenta espectacularmente la interoperabilidad, 
por ejemplo en los típicos documentos de oficina. Ésta es la emoción 
principal que se esconde tras la revolución XML: evitar la pérdida de 
información cuando esos documentos se traducen a HTML y por tan- 
to pierden su capacidad de ser entendidos como hojas de cálculo, ca- 
lendarios, resúmenes bancarios o lo que sea. 
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Lo malo es que cuando una compañía introduce un nuevo tipo de 
documento, nadie más lo entienda. El XML facilita el que todo el 
mundo cree sus propias etiquetas o lenguajes de markup completos. 
Podremos por lo tanto ver el fin de la idílica situación que ha prevale- 
cido hasta ahora en el Web; el predominio del HTML, que nos ha 
ayudado a todos a compartir fácilmente. ¿Será posible que, tras una 
década de existencia del Web, el XML nos dé una libertad que forzo- 
samente conduzca de nuevo a una miríada de lenguajes incompati- 
bles? Esto es una posibilidad muy seria, pero que ha sido prevista. 

La X de extensible en XML significa que cualquiera puede inven- 
tar nuevas etiquetas pero no pueden añadirlas a las etiquetas de otro. 
Un documento XML puede hacerse con una mezcla de etiquetas de 
más de un namespace, pero cada namespace está identificado con un 
URI. Por tanto, cualquier documento XML está completamente defi- 
nido usando el Web. Éste es un enorme paso hacia delante desde los 
viejos días del HTML, en los que cualquiera podía organizar su pro- 
pia versión de lo que quería decir <tabla>, por ejemplo, sin ninguna 
ambigúedad. Los namespaces XML cambian las reglas de la evolu- 
ción tecnológica haciendo que cada paso esté, bien sea abierto, bien 
sea privado, perfectamente definido. 

Es importante recordar que el XML no sustituye al HTML. Susti- 
tuye al SGML sobre el que estaba construido el HTML. El HTML 
puede ahora escribirse como XML. De hecho, es posible crear un do- 
cumento XML válido que también funcione con los viejos navegado- 
res HTML. (La especificación para hacer esto es XHTML.) 


Cuando presenté el Web en 1989, la fuerza motora que tenía en mente 
era la comunicación por medio del conocimiento compartido, y el 
“mercado” motor para ello era la colaboración entre las personas en el 
trabajo y en casa. Al construir un Web de hipertexto, un grupo de per- 
sonas de cualquier tamaño podría expresarse fácilmente, adquirir y 
transmitir rápidamente conocimientos, superar los malentendidos y 
reducir la duplicación del esfuerzo. Esto daría a la gente integrante de 
un grupo una nueva fuerza para construir algo conjuntamente. 

La gente también tendría un modelo en marcha de sus planes y ra- 
zonamientos. Una red de conocimientos vinculada por medio del hi- 
pertexto contendría una fotografía de su comprensión compartida. 
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Cuando nuevas personas se unieran al grupo, tendrían a su disposi- 
ción las decisiones y razonamientos para revisarlos. Cuando alguna 
persona dejase el grupo, su trabajo ya habría sido recogido e integra- 
do. Como emocionante cualidad extra, el análisis mecánico de la red 
de conocimientos podría quizá permitir a los participantes sacar con- 
clusiones acerca del manejo y organización de.su actividad colectiva 
que de otro modo no habría podido tener claras. 

La intención era que el Web se usara como un sistema de informa- 
ción personal, y una herramienta de grupo a cualquier escala, desde el 
equipo de dos personas que crean un panfleto para la obra de la es- 
cuela elemental local, hasta la población mundial decidiendo acerca 
de temas ecológicos. 

Yo también quería que el Web se usara tanto “internamente” 
como externamente. Aunque la mayoría de los diez primeros servido- 
res, como el del CERN o el de SLAC, se llamarían hoy servidores ¿n- 
tranel, las organizaciones y las familias están sólo empezando a ver la 
potencia que el Web puede aportarles. Aunque cuesta un poco de tra- 
bajo conseguir el control de acceso para una red interna (intranet) de 
empresa o familiar, una vez que esto se ha hecho, la utilidad del Web 
se acelera, porque los participantes comparten un nivel de confianza. 
Esto estimula una comunicación más espontánea y directa. 

Para poder trabajar realmente juntos en el Web, necesitamos he- 
rramientas mucho mejores: mejores formatos para presentar la infor- 
mación al usuario; interfaces más intuitivos para editar y cambiar la 
información; integración inmediata de otras herramientas, como 
chats, y audio y videoconferencias, con edición web. Necesitamos la 
capacidad de almacenar en un servidor una anotación sobre una pági- 
na web en otra; controles de acceso más sencillos para grupos miem- 
bros, y para localizar los cambios en documentos. Mientras que parte 
de este trabajo supone llevar a cabo investigaciones punteras, gran 
parte de él consiste en tratar de adaptar los sistemas informáticos exis- 
tentes al mundo global del hipertexto. 


Para que la gente comparta conocimientos, el Web debe ser un espa- 
cio universal a través del cual puedan viajar todos los vínculos de hi- 
pertexto, Yo me paso una buena parte de mi vida defendiendo esa 
propiedad fundamental de un modo u otro. 
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La universalidad debe existir a lo largo de diversas dimensiones. 
Para empezar, tenemos que poder intervincular cualquier documento, 
desde borradores hasta trabajos muy bien terminados. La informa- 
ción se pierde a menudo dentro de una organización cuando un “do- 
cumento final” de cualquier tipo se crea al final de un esfuerzo. Á me- 
nudo, todo, desde las actas de las reuniones hasta investigaciones de 
fondo desaparece, y los razonamientos que llevaron al grupo a sacar 
sus conclusiones se pierden. Puede en realidad seguir existiendo en al- 
guna patte de un disco, pero no sirve de nada porque el documento fi- 
nal no puede vincularse a él. Es más, diferentes sistemas sociales y 
prácticos aíslan documentos de diferentes niveles los unos de los 
otros: no metemos notas al azar en libros terminados pero ¿por qué 
no lo hacemos si son relevantes y tienen contenido? Actualmente en el 
consorcio nadie puede mencionar un documento en una reunión a 
menos que pueda proporcionar su URI. Nuestra política es: “Si no 
está en el Web, no existe”, y el grito que más se oye cuando se presenta 
una nueva idea es: “¡Mételo en Team Space!”, un directorio para at- 
chivar confidencialmente documentos que de otro modo no estarían 
en el Web. Todo el correo es archivado instantáneamente en el Web 
con un URI persistente. Ya es difícil imaginar cómo podría hacerse de 
otra forma. El Web para trabajar y jugar debe ser capaz de entretejer 
ideas a medio cocer e ideas totalmente cocidas, y la tecnología web 
debe poder sostenerlas. 

Otra dimensión crítica para la universalidad es la capacidad para 
vincular material local con material global. Cuando se hace un esfuer- 
zo que reúne a grupos de diferentes escalas, ya sea un proyecto de in- 
geniería de software como el mío del CERN, o un proyecto de una es- 
cuela de educación elemental que es parte de una iniciativa municipal 
y usa fondos gubernamentales, la información tiene que venir de mu- 
chos niveles y tiene que estar interrelacionada. 

De igual modo, la universalidad tiene que existir a través del es- 
pectro de coste e intención. Las personas y las organizaciones tienen 
motivaciones diversas. a la hora de meter una información en el Web: 
para su propio beneficio, para fines lucrativos, para el bien de la socie- 
dad o para lo que sea. Para que un sistema de información sea univer- 
sal, no puede discriminar entre estas cosas. El Web tiene que incluir 
información que sea gratuita, muy cara, y todo lo que queda entreme- 
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dias. Debe permitir a todos los diversos grupos de interés reunir todo 
tipo de precios, adquisición de derechos y sistemas de incentivos... y 
siempre, naturalmente, permitir al usuario decir “no”. 

La razón por la que necesítamos la universalidad a todos estos ni- 
veles es que ésa es la forma en que funciona la gente en el mundo real. 
Si el World Wide Web va a representar y sostener la red de la vida, tie- 
ne que permitirnos operar de diferentes formas con diferentes grupos 
de diferentes tamaños y perspectivas en lugares diferentes cada día: 
nuestras casas, oficinas, escuelas, iglesias, pueblos, estados, países y 
culturas. Debe también trascender los niveles, porque la gente creati- 
va siempre está cruzando fronteras. Así es como resolvemos proble- 
mas e innovamos. 

La información debe poder ser capaz de cruzar también las fron- 
teras sociales. Nuestra vida familiar está influenciada por el trabajo. 
Nuestra existencia en un grupo afecta a lo que hay en otro. Los valo- 
res y las acciones se alimentan de todas las ideas salidas de esas zonas 
diversas. Conectándose por medio de grupos, las personas también 
hacen que el mundo sea más consistente y organizado. Es poco co- 
rriente que un individuo apoye políticas medioambientales a nivel glo- 
bal y luego decida tirar productos químicos al río más cercano. 

Mi visión original de un Web universal era una ayuda de sillón 
para ayudar a la gente a hacer cosas en la red de la vida real. Sería un 
espejo que reflejase informes o conversaciones o arte, y trazase inte- 
racciones sociales. Pero cada vez más el modelo del espejo está equi- 
vocado, porque la interacción está teniendo lugar sobre todo en el 
Web. La gente usa el Web para construir cosas que no han construido, 
escrito, dibujado o comunicado en ningún otro lugar. Como el Web se 
está convirtiendo en un espacio primario de una gran actividad, tene- 
mos que tener cuidado de que contribuya a crear una sociedad justa. 
El Web debe dar acceso igual a aquellos que estén en situaciones eco- 
nómicas y políticas diversas; aquellos que tengan discapacidades físi- 
cas o psíquicas; aquellos que tengan culturas diferentes; y aquellos 
que usen diferentes lenguas con diferentes caracteres que se lean en 
diferentes direcciones a través de una página. 


El factor más simple que controla el Web como medio de comunica- 
ción entre la gente es la potencia de los formatos de datos usados para 
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representar hipertexto, gráficos y otros medios de comunicación. Muy 
presionados debido a su visibilidad directa y a su impacto en la expe- 
riencia del usuario, éstos han avanzado relativamente rápido, porque 
cada medio ha sido esencialmente independiente de los demás. 

Podríamos haber esperado que los formatos de gráficos se hubie- 
ran estandarizado hace tiempo, pero el Web introdujo nuevas exigen- 
cias que están conduciendo a una gran evolución. Marc Andreessen 
dio a los navegadores la capacidad de mostrar gráficos dentro de un 
documento, en lugar de relegarlos a una ventana separada. Recogió el 
Graphic Interchange Format (GIF) definido por CompuServe. Pron- 
to la gente empezó a usar también el formato estándar JPEG (Joint 
Photographic Experts Group) para fotógrafos. Estos dos formatos 
reinaron hasta que Unisys anunció que había acabado siendo el dueño 
de una patente de la tecnología de compresión usada para hacer imá- 
genes GIF y que iban a cobrar tasas de licencia. Un pequeño grupo de 
entusiastas propuso una alternativa, Portable Network Graphics 
(PNG), basada en una tecnología de compresión abierta y general- 
mente superior al GIF. Los miembros del consorcio accedieron a res- 
paldar el PNG como recomendación W3C. 

Las últimas tendencias que colocan al Web en todas partes, desde 
la televisión a las pantallas de los teléfonos móviles han convertido la 
necesidad de la dependencia del aparato en algo muy claro. Esto ha 
hecho que aparezcan formatos de gráficos más nuevos aún que son 
más capaces de mostrar una imagen en pantallas de diversos tamaños 
y tecnologías. Tanto el JPEG como el PNG describen una imagen en 
términos de la trama cuadrada de pzxels que forman una pantalla de 
ordenador. El consorcio está desarrollando un nuevo formato para di- 
bujos que los describirá como formas abstractas, dejando al navega- 
dor libre de llenar-los pixels de tal modo que la imagen pueda mos- 
trarse con óptima claridad en un reloj de pulsera o en la pantalla de un 
cine al aire libre. El formato, llamado gráficos vectoriales escalables 
(scalable vector graphics), se basa en el XML. También acelerará espec- 
tacularmente la entrega de documentos que contengan dibujos, lo que 
abrirá la puerta a toda clase de nuevas maneras de interactuar entre 
una persona y un sitio web. Y como está en XML, será fácil para los 
principiantes leer y escribir. Pronto veremos todo-tipo de interfaces 
gráficos animados. 
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El Virtual Reality Modeling Language [Lenguaje Modelador de 
Realidad Virtual] (VRML) es otro pilar, que fue creado para escenas 
tridimensionales. Yo esperaba que 3D despegase realmente, y aún no 
entiendo por qué no ha sido así. Enviar detalles de una escena 3D re- 
quiere de relativamente pocos bytes comparado con el vídeo, por 
ejemplo. Requiere un ordenador más rápido del usuario, para mani- 
pular la escena a medida que el usuario se mueve a su alrededor. Qui- 
zá la potencia del procesador medio no sea aún lo suficientemente 
alta. 

Integrar muchos medios de textos, imágenes, audios y vídeos dife- 
rentes en una página o espectáculo web será algo a lo que contribuirá 
en gran medida el Synchronized Multimedia Integration Language 
(SMIL, “smile” [sonrisa]). El SMIL hará que la coordinación sincro- 
nizada sea sencilla, incluso para autores con limitada experiencia en 
diseño web. Las conocidas cintas de Clinton, difundidas por el Web 
en ventanas con mezclas de gráficos, texto y vídeo, no eran más que 
un lanzamiento del SMIL. El lenguaje también puede ahorrar con 
efectividad anchura de banda. Á menudo una señal de televisión 
—como un programa de noticias— tiene una cabeza parlante que 
ocupa quizá un cuarto de la pantalla, una imagen inmóvil o un mapa 
en el fondo, y quizá un comentario escrito, por no hablar de los resul- 
tados de fútbol o baloncesto que van pasando por la parte de debajo 
de la pantalla. Transmitir todo esto como datos de vídeo requiere mu- 
cha anchura de banda. El SMIL permite que la relativamente pequeña 
cantidad de datos acerca de las imágenes que están realmente movién- 
dose se manden como vídeo, y se integren con las imágenes fijas que 
son transmitidas a la pantalla del usuario de un modo que requiere 
mucha menos anchura de banda. 

Todos los trabajos acerca del hipertexto, los gráficos y los lengua- 
jes multimedia comparten una preocupación del acceso para todos, 
independientemente de la cultura, la lengua y la discapacidad. El Web 
Accesability Initiative (Iniciativa de Accesibilidad) del consorcio reú- 
ne a gente de la industria, las organizaciones para discapacitados, el 
gobierno y laboratorios de investigación para que emitan protocolos y 
software que permitan que el Web sea accesible a personas con disca- 
pacidades visuales, auditivas, físicas y cognitivas o neurológicas. El 
trabajo es muy amplio, y va desde la revisión de las tecnologías W3C 
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para asegurar que apoyen la accesibilidad, basta el desarrollo de direc- 
tivas de accesibilidad a sitios web, navegadores y herramientas de crea- 
ción, y desarrollo de herramientas para evaluar la accesibilidad. La 
mayoría de todo esto funciona sólo cuando los que hacen sitios web se 
preocupan un poco por el modo en que lo han hecho, La discapaci- 
dad y las comunidades técnicas caminan juntas para hacer una serie 
de directivas acerca de los pasos más efectivos a seguir: lectura reco- 
mendada para maestros del Web. 

El consorcio también tiene una actividad de internacionalización 
que se asegura de que las nuevas especificaciones funcionen en dife- 
rentes alfabetos, ya sean orientales u occidentales, leídos de derecha a 
izquierda, de izquierda a derecha o de arriba abajo. Las conversiones 
pueden ser complicadas, pero la industria informática está haciendo 
enérgicos esfuerzos para ampliar los sistemas operativos que permitan 
mostrar todo tipo de escrituras, entre ellas la árabe, la hindi, la corea- 
na, la china, la japonesa, la thai y la hebrea. HTML 4.0 ya proporciona 
varias características de internacionalización, incluyendo la posibili- 
dad de marcar texto según la lengua en que esté, y la de ordenar texto 
de derecha a izquierda. 

El principio primario que se encuentra tras la independencia de 
los aparatos, y la accesibilidad, es la separación de forma y contenido. 
Cuando el significado de un documento se almacena separadamente 
del modo en que debe ser mostrado, la independencia del aparato y la 
accesibilidad se vuelven mucho más fáciles de mantener. Gran parte 
de esto se logra con una hoja de estilo, un conjunto de instrucciones 
sobre cómo presentar o transformar una página escrita. Hakon Lie, 
que trabajó conmigo en el CERN y más tarde en el consorcio, condujo 
el desarrollo de las Cascading Style Sheets [Hojas de Estilo en Casca- 
da] (CSS) para que eso fuera posible. Un nuevo lenguaje relacionado 
con diferentes capacidades, el XSL, está también en marcha. Hay in- 
cluso un lenguaje “auricular” de estilo de hoja de sonido (“aural”), 
parte de la CSS2, para explicar a un navegador cómo debe sonar una 
página web. 

La lista creciente de formatos de gráficos está relacionada básica- 
mente con displays estáticos. Pero algunas personas piensan que una 
página web no es lo bastante emocionante si no se mueve. Como míni- 
mo, quieren que la página cambie cuando un usuario interactúa con 
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ella. Bocadillos y menús, o formularios que se rellenan solos son senci- 
llos ejemplos de lo que hoy día encontramos en el Web. Esto funciona 
porque un pequeño programa, o script, se carga con la página. Hace 
funcionar la página como la mano dentro de la marioneta, en respues- 
ta alas acciones del usuario. Esto ha creado una crisis en la interopera- 
bilidad, sin embargo, porque la conexión entre el script y la página 
web, la mano y la marioneta, no es estándar para diferentes clases de 
hojas de estilo. Para solucionar esto, el consorcio está trabajando en un 
Document Object Model [Modelo de Objeto Documento] (DOM), 
un conjunto de estándares para ese interface. Por desgracia, es mucho 
más difícil hacer que estas páginas animadas sean accesibles a navega- 
dores de voz y lectores de pantalla. En la parte positiva, el interface 
DOM debería proporcionar un modo potente para herramientas de 
accesibilidad, como lectores de documentos para acceder a la estruc- 
tura del documento que está dentro de un navegador. 


Los medios de comunicación pueden mostrarnos el Web como un lu- 
gar maravilloso e interactivo donde tenemos una posibilidad de elegir 
ilimitada porque no tenemos que limitarnos a lo que el productor de 
televisión ha decidido que tenemos que ver a continuación. Pero mi 
definición de lo interactivo incluye no sólo la capacidad de escoger, 
sino también la capacidad de crear. Deberíamos ser capaces no sólo 
de encontrar cualquier tipo de documento en el Web, sino también 
crear cualquier clase de documento fácilmente. Deberíamos no sólo 
poder seguir vínculos, sino crearlos, entre todo tipo de medios. Debe- 
ríamos no sólo poder interactuar con otras personas, sino crear con 
otras personas. La intercreatividad es el proceso de hacer cosas o resol- 
ver problemas juntos. Si la interactividad no es sólo sentarse pasiva- 
mente delante de una pantalla, entonces la ¿ntercreatividad no es sólo 
sentarse frente a algo “interactivo”. 

Con todo este trabajo en la presentación del contenido, seguimos 
sin habernos dirigido más que a la lectura de información, no a su es- 
critura. Hay que contribuir a que el Web sea un lugar de colaboración. 
Al darse cuenta de esto, el consorcio organizó un taller para descubrir 
qué era lo que se necesitaba. El resultado fue una larga lista de la com- 
pra de las posibilidades, cosas como la sólida autenticación de los 
miembros de grupos, buenos editores de hipertexto, sistemas de ano- 
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tación (semejantes a las notas de papel adhesivo amarillo) y herramien- 
tas para procedimientos como el voto en línea. 

Algunos de los resultados han sido satisfactorios. El SMIL fue uno 
de ellos; integraba varios medios y posiblemente permitía que se cons- 
truyera un medio ambiente de colaboración en tiempo real, una sala 
de reuniones virtual. Otros están aún pendientes. Un objetivo que yo 
tenía desde hacía tiempo era encontrar un navegador intuitivo que 
además, como mi WorldWide Web, permitiera editar. Se han hecho 
unos cuantos editores/navegadores, como AOL press, pero ninguno 
fue apoyado como producto comercial. Pocas cosas se llevaron a cabo 
de las que había en la lista de herramientas de colaboración. En el 
consorcio nos preguntamos qué pasaba. ¿Es que la gente no quería 
esas herramientas? ¿Los empresarios eran incapaces de visualizarlas? 
¿Por qué años de discursos, escritura especulativa y ánimos no llega- 
ban a ninguna parte? 

Yo estaba cada vez más convencido de que la única manera de des- 
cubrir lo que estaba impidiendo el desarrollo de las herramientas de 
colaboración era que tratásemos de desarrollarlas nosotros mismos. 
Nuestra política había sido siempre la de que usaríamos las herramien- 
tas comerciales que estuvieran disponibles para conseguir hacer nues- 
tro trabajo. En un retiro del equipo del consorcio en Cambridge, suge- 
tí que empezáramos a probar todas las soluciones experimentales que 
andaban por ahí, e.incluso desarrollarlas más. Quizá entonces descu- 
briríamos los auténticos problemas, y veríamos así el camino hacia la 
solución. 

Concluimos que para hacer esto, necesitábamos un núcleo de 
personas que pusiesen a prueba nuevas tecnologías de colaboración, 
sólo para ver qué pasaba. Ayudarían a todo el personal del consorcio 
a convertirse en los primeros usuarios de un software experimental, 
Esta nueva política, que llamamos Live Early Adoption and De- 
monstration [Adopción y Demostración Temprana] (LEAD), signi- 
ficaba que nosotros nos lo guisábamos y nosotros nos lo comíamos, 
hasta donde nos permitían nuestros escasos recursos. Significaba 
que íbamos a estar poniendo a prueba nuevos protocolos no como 
cosas aisladas, sino en el contexto de nuestro trabajo diario, del mo- 
mento. También significaba que, con sólo un puñado de programa- 
dores, estaríamos tratando de mantener la fiabilidad de esos produc- 
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tos experimentales a un nivel lo bastante alto como para permitirnos 
usarlos de verdad. 

Estamos sólo en las primeras etapas, pero sabemos que tenemos 
ahora un medio en el que las personas que están colaborando con el 
consorcio escriben y editan hipertexto, y archivan los resultados en 
nuestro servidor. Amaya, el navegador/editor, maneja HTML, XML, 
Cascading Stylesheets, Portable Network Graphics y un prototipo de 
Scalable Vector Graphics y Math ML. Mientras que siempre hemos 
desarrollado Amaya en el sistema operativo Linux, el equipo Amaya 
lo ha adaptado para la plataforma Windows NT, habitual en el mundo 
de los negocios, también. Yo estoy ahora llevando a cabo tests de las 
últimas versiones de esas herramientas en cuanto puedo conseguirlas, 
mandando informes derrotistas en los días malos y de vez en cuando 
una botella de champán en uno bueno. 

Estamos usando nuestro servidor basado en Java de fuente abier- 
ta, Jigsaw, para trabajo en colaboración. Por ejemplo, Jigsaw permite 
la edición directa, guarda las diversas versiones editadas de un docu- 
mento, y sigue la pista de lo que se ha cambiado de una versión a otra. 
Yo puedo ver una lista de todas las versiones, con detalles acerca de 
quién hizo qué cambios cuándo, y volver a ponerlo en una versión más 
antigua si es necesario. Esto le da a todo el mundo una sensación de 
seguridad, y se sienten más inclinados a compartir la edición de un 
trabajo. Jigsaw y Amaya permiten a nuestro equipo cobrar vida como 
nuestra sala común, biblioteca interna y máquina del café virtual alre- 
dedor de la cual los miembros del personal que están en Francia, Mas- 
sachusetts, Japón o en un avión, se pueden reunir. 

Hacer trabajo de colaboración es un desafío. También es diverti- 
do, porque afecta a los fundamentos y aspecto universitario de la co- 
munidad web. Cualquier código web, desde mi primer lanzamiento 
en 1991, ha sido software de fuente abierta: cualquiera puede sacar el 
código fuente —las líneas de programación— y editarlo y reconstruir- 
lo, gratis. Los miembros de la lista de correo www-talk original reco- 
gían rutinariamente nuevas versiones de la biblioteca original de có- 
digos web “libwww”. Este software aún existe en el servidor público 
del consorcio, 1w10w.103.o0rg, mantenido durante muchos años por 
Henrik Nielsen, el alegre danés que lo manejó en el CERN y ahora en 
el MIT. Libwww se usa como parte de Amaya, y el resto de Amaya y 
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Jigsaw son de fuente abierta de igual modo. Hay mucha gente que 
puede no desear unirse a grupos de trabajo y editar especificaciones, 
pero les gusta unirse a la creación de un buen software. Aquellos a 
quien les apetece probar Amaya o Jigsaw, que quieran ayudar a mejo- 
rarlos, desarrollar un producto basado en ellos, o deseen sacar el códi- 
go y crear un cliente o servidor mejores, pueden simplemente ir al si- 
tio w3.org y sacarlo de allí, ya sean o no miembros del consorcio. 
Creamos otras herramientas a medida que las necesitamos, y nues- 
tro equipo de creación de herramientas siempre está muy solicitado. 
Los registros, el manejo de listas de correos y el control de nuestro sitio 
web son ejemplos típicos. Esperamos el momento en que podamos 
usar criptografía de clave pública para autentificar colaboradores. De 
vez en cuando los nuevos sistemas se estropean, y nosotros pagamos el 
precio de estar en el filo de la navaja porque tenemos que esperar a que 
se arreglen. Pero vamos entendiendo mejor lo que costará conseguir el 
sueño de la colaboración por medio de los conocimientos compartidos. 


Espero que esas herramientas se desarrollen hasta formar un nuevo 
género común en el Web. La vida real está y debe estar llena de todo 
tipo de presiones sociales; los mismísimos procesos de los que surge la 
sociedad. Los ordenadores ayudan si los usamos para crear 724quinas 
sociales abstractas en el Web: procesos en los que la gente hace el tra- 
bajo creativo y la máquina se ocupa de la administración. Muchos 
procesos sociales pueden funcionar mejor en una máquina, porque la 
máquina está siempre disponible, está libre de prejuicios y además a 
nadie le gusta administrar ese tipo de sistema. Las votaciones en línea 
son un ejemplo, y ya están teniendo lugar: ADP Investor Communica- 
tions y el First Chicago Trust tiene servicios que llevan a cabo votacio- 
nes en línea por procuración para reuniones de accionistas, y más de 
mil compañías están usándolos. 

La gente ya está experimentando con nuevas máquinas sociales 
para la supervisión en línea de los compañeros de trabajo, mientras que 
otras herramientas, como los chats, se desarrollaron de manera bas- 
tante independiente y antes del Web. Los MUDDs son herramientas 
sociales derivadas de los juegos de multiusuarios Dragones y Mazmo- 
rras, en los que miles de personas adoptaban papeles e interactuaban 
en un mundo global de fantasía en línea. Experimentando con estas 
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estructuras podemos encontrar un modo de organizar nuevos modelos 
sociales que no sólo se adapten bien, sino que puedan combinarse para 
formar estructuras cada vez mayores. 

Hace ahora casi una década, pedí a Ari Luotonen que pasara tres 
días escribiendo una herramienta de conversación para el naciente 
Web. Iba a ser como un grupo de noticias, pero captaría la lógica de 
una discusión. Siempre me había frustrado el que el papel esencial de 
un mensaje en una discusión fuese a menudo información perdida. 
Cuando Ari acabó, en cualquier lugar del servidor del CERN en el 
que creásemos un subdirectorio llamado Discusión, existiría un nuevo 
forum interactivo. Permitía a la gente enviar preguntas sobre un tema 
determinado, leer y responder. Una persona no podía limitarse a 
“contestar”. Tenía que decir si estaba de acuerdo, en desacuerdo, o 
pedir una aclaración. La idea era que el estado de una discusión fuese 
visible para cualquiera que participara. 

Me gustaría que cualquier tema serio estuviera en el Web como hi- 
pertexto. Me gustaría que existieran servidores de anotaciones donde 
los grupos pudieran añadir vínculos (o post-its) a documentos que 
quisieran comentar. Los servidores de anotaciones son un servicio de 
terceras partes que permiten a un grupo compartir los comentarios de 
los demás acerca de documentos que estén en cualquier otro lugar del 
Web. El navegador va a la página original y luego comprueba por se- 
parado los servidores de anotaciones buscando comentarios, que lue- 
go se superponen en la página. Imaginemos que tenemos servidores 
para hacer comentarios en diferentes forums, quizá la familia, la es- 
cuela y la empresa. Cada punto y su refutación están vinculados, así 
que todo el mundo puede ver al primer vistazo los acuerdos directos, 
las contradicciones y las pruebas de apoyo de cada punto de vista, de 
modo que la gente implicada puede contestar a cualquier cosa. Si hu- 
biera cualquier tipo de proceso judicial y democrático para resolver 
los temas, la discusión podría hacerse de una manera muy clara y 
abierta, mientras un ordenador fuera registrando los argumentos. Una 
vez más el tema son los seres humanos pensando y las máquinas ayu- 
dando a que eso funcione a una escala mayor, pero sin que nada susti- 
tuya al final a la sabiduría y la prudencia. 

Mi esperanza era que la idea original de la “Discusión”, y los futu- 
ros mecanismos que pudiera evolucionar a partir de ella en el nuevo 
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Web, nos haría avanzar más allá de la situación histórica de la gente ti- 
rándose barro unos a otros, o condimentando sus discusiones con ata- 
ques personales y vitriolo, y sustituirlo todo con un debate razonado y 
socrático, en el que las ideas individuales, las acusaciones y las prue- 
bas testimoniales pudieran ser cuestionadas o confirmadas. 

Lo que Ári y yo intentábamos hacer era crear una máquina que hi- 
ciera el trabajo de administración de un tribunal, por ejemplo, o de un 
grupo de trabajo o parlamento. La prueba inicial fue una discusión 
por el placer de la discusión, y no tuvo mucha repercusión. Ahora hay 
varios productos de software para hacer algunas de esas cosas. Para 
emular realmente una sala de tribunal o un proceso de voto democrá- 
tico, sin embargo, las herramientas tienen que desarrollarse mucho 
más. Yo espero un desplazamiento del argumento por repetición de 
fragmentos de sonido a una exposición de hipertexto que pueda justi- 
ficarse y rebatirse; una exposición que nos permita mirar y comparar, 
lado a lado, lo que los políticos, o los defensores y acusadores, digan 
en realidad, sea lo que sea lo que se diga en anuncios de televisión o 
entrevistas nocturnas. E 

Como serían de bajo coste, las máquinas sociales nos permitirían 
hacer cosas que no podíamos hacer antes. Por ejemplo, nos permiti- 
rían llevar a cabo un plebiscito nacional cuyo coste sería de otro modo 
prohibitivo. Esto, naturalmente, igual que todos los beneficios de esta 
nueva tecnología, sé inclinaría del lado de los que tienen acceso a In- 
ternet. Esto es sólo un ejemplo para mostrar que podemos reconside- 
rar lo que es posible; yo no estoy preconizando trasladar la democra- 
cia representativa a la democracia directa. Debemos tener cuidado de 
no hacer las cosas sólo porque son posibles. 

Quizá el Web permita unas formas de gestión más orgánicas, en 
las que grupos dentro de una compañía se formen de un modo local. 
Podrían autoformarse como un grupo de noticias, pero con las restric- 
ciones que aseguren que quien se una sea necesario para el trabajo de 
la compañía y esté cubierto con el presupuesto suficiente. Más allá de 
esto, la compañía no tiene por qué tener una estructura convencional. 
Cuando alguien tenga una tarea que realizar, se asocia con quien sea 
necesario para que esa tarea se realice. La gente establece compromi- 
sos y los negocia entre grupos, sin necesidad de director. La totalidad 
de la organización orgánica podría crecer a partir de una semilla de 
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unos pocos documentos firmados digitalmente en el Web, sobre el 
sustrato de una constitución electrónica que defina cómo operan las 
máquinas sociales. Las disposiciones para enmendar la constitución 
tendrían previstos los cambios. Unas cuantas reglas minimalistas ase- 
gurarían el “fair play”. 

Mientras que.estos nuevos sistemas sociales.son muy emocionan- 
tes porque son esencialmente independientes en lo que se refiere a lu- 
gar, raza y religión, aislarán naturalmente a aquellos que estén en paí- 
ses en vías de desarrollo que no puedan permitirse o no tengan opción 
a acceder a Internet. Á la vez gran equiparador y gran divisor, el Web 
subraya igual que lo hacen el agua potable y la atención sanitaria la ne- 
cesidad de que los más privilegiados se ocupen, pero no controlen, a 
los menos privilegiados. Me limitaré a tocar de pasada ese urgente de- 
bate aquí. 

Ya está montado el escenario para el crecimiento evolutivo de 
nuevos motores sociales. La capacidad para crear nuevas formas de 
proceso social será dada a todo el mundo, y el desarrollo será rápido, 
igual que la condición abierta de la tecnología web permitió que ésta 
floreciese. 

Mis colegas y yo nos hemos preguntado si deberíamos impulsar 
este proceso usando al propio consorcio. Podríamos construir la má- 
quina social del consorcio con las muchas máquinas que forman los 
grupos de trabajo, las reuniones del personal, etc. Podríamos permitir 
que un conjunto de grupos de trabajo que formasen un puñado estre- 
cho independiente se separasen y creasen un nuevo consorcio similar 
“clónico”. Las reglas tendrían que incluir más que un voto semejante 
al de los grupos de noticias; los presupuestos y las contribuciones ten- 
drían que equilibrarse, y la responsabilidad tendría que ser aceptada. 
En teoría, podríamos entonces generalizar esta nueva forma social. 
Luego cualquiera podría poner en marcha un consorcio, cuando las 
condiciones fuesen las adecuadas, apretando unos cuantos botones en 
la página web de una “fábrica de consorcios” virtual. 


13. LAS MÁQUINAS Y EL WEB 


Cuando la gente se comunica a través del Web, los ordenadores y las 
redes tienen como función habilitar el espacio de la información, y 
luego quitarse de en medio. Pero ¿no tendría sentido hacer actuar más 
a los ordenadores, poner su capacidad analítica a trabajar, dando sen- 
tido al enorme contenido y discurso humano que hay en el Web? En la 
parte dos del sueño, eso es exactamente lo que hacen. 

El primer paso es colocar datos en el Web de una forma que las 
máquinas puedan entenderlos de manera natural, o convertirlos a esa 
forma. Esto crea lo que yo llamo un Web Semántico; una red de datos 
que pueden ser procesados directa o indirectamente por máquinas. 

Consideremos la limitada cantidad de ayuda que hemos recibido 
hasta ahora en el Web de las máquinas. Los aparatos de búsqueda han 
demostrado ser muy útiles para combinar largos índices rápidamente 
y para encontrar oscuros documentos. Pero han demostrado ser nota- 
blemente inútiles, también porque no tienen modo de evaluar la cali- 
dad de un documento. Suministran mucha basura. El problema es 
que los aparatos de búsqueda suelen limitarse a ver la existencia de 
palabras en documentos; algo que es una pista, pero que nos dice muy 
poco de lo que realmente dice o trata el documento. 

Un poco más sofisticados son los servicios automáticos de inter- 
mediación (brokerage), que empezaron a surgir en 1998. Son sítios 
web que tratan de poner de acuerdo a compradores y a vendedores. 
Desde la perspectiva del comprador, un servicio así puede parecer 
como una metatienda: una tienda de tiendas. Una metatienda es web- 
market.com: le damos el nombre de un libro, y lo buscará en todas las 
librerías en línea que conozca, comprobará los precios y presentará 
una lista competitiva. Para buscar realmente en los catálogos de las li- 
brerías, tiene que pretender ser un comprador navegador, poner en 
marcha sus buscadores, y luego sacar los datos resultantes acerca del 
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producto, del precio y de la entrega. Entonces puede preparar una ta- 
bla que compare cada oferta. 

El truco de hacer que un ordenador extraiga información de un 
catálogo en línea no es más que eso: un truco. Es conocido como 
screen scraping: tratar de recuperar algo utilizable a partir de una in- 
formación que está ahora en una forma sólo adecuada para los huma- 
nos. Es poco fiable porque el catálogo puede cambiar de formato de 
un día para otro —por ejemplo, poniendo el número de ISBN donde 
solía estar el precio— y el broker automático se confundiría. 

A medida que la gente aprende a usar el Web, lo analizan de mu- 
chas formas. El “ego surfing” —buscar coincidencias con el nombre 
de uno— es un ejemplo simple. Puede parecer narcisista, pero es una 
búsqueda razonable, porque tenemos cierta responsabilidad en des- 
cubrir cómo encajamos en el mundo. La investigación en línea es un 
ejemplo más serio. Uno trata de encontrar no sólo la respuesta a una 
pregunta, sino también qué estructuras puede haber en la informa- 
ción. 

Tomemos por ejemplo a un escritor que quiere influenciar a los 
que toman decisiones en Pakistán y la India, y que están jugando con 
el posible uso de armas nucleares. Quiere que sean conscientes del ho- 
rror del día después del bombardeo atómico en Nagasaki. Necesita 
conocer los foros en los que operan dichas personas, lo que leen. Ne- 
cesita fuentes de información sobre armas nucleares. Necesita cone- 
xiones actuales entre la gente, los foros y las fuentes de información. 
Las estructuras y las interrelaciones son importantes. 

El mismo tipo de análisis web puede descubrir nuevos mercados. 
Puede contribuir a que el líder del equipo que lleva a cabo un proyec- 
to evalúe los trabajos de su equipo trazando un esquema de todas las 
dependencias y relaciones entre la gente, las actas de reuniones, la in- 
vestigación y otro materiales relacionados con el grupo, que juntos de- 
finen cuál es la marcha del proyecto. Un ejecutivo jefe querría poder 
analizar el funcionamiento de su empresa. Imaginemos que recibe un 
informe a través de la línea de: “La compañía va bien, excepto en un 
par de cosas. Tiene una sección de recambios en Omaha que tiene 
exactamente la misma estructura y esquema de negocio que una com- 
pañía en Detroit que acaba de fracasar. Puede que quiera observar 
esto más de cerca. Hay un producto que hace usted que está perfecta- 
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mente documentado pero que no se usa. Y parece haber unos cuantos 
empleados que no hacen nada que contribuya en absoluto al bien de 
la compañía”. : 

Estos análisis no pueden ser automatizados actualmente, en parte 
porque la forma de inteligencia que puede llevar a cabo ese tipo de 
conclusiones es ya bastante difícil de encontrar en las personas, cuan- 
to más en un programa de ordenador. Pero una razón más sencilla es 
que muy poca de la información que hay en el Web se encuentra en 
una forma que pueda entender una máquina. El Web Semántico ataja 
este sencillo problema; quizás al final como fundamento para atajar el 
problema más grande. 

Actualmente, cuando una persona manda una nota a un sitio web 
para vender, por ejemplo, un coche amarillo, es casi imposible que 
otra persona lo encuentre. Buscar un “coche amarillo a la venta en 
Massachusetts” da como resultado un enorme número de páginas que 
resulta que contienen esas palabras, cuando de hecho la página que 
quiero ver puede ser acerca de un “Honda, anda bien, cualquier ofer- 
ta” con un número de teléfono de Boston. El buscador no entiende la 
página, porque está escrita para un lector humano que sabe inglés y 
tiene mucho sentido común. 

Esto cambia cuando el vendedor usa un programa (o sitio web) 
que le permite rellenar un formulario acerca de un objeto para vender. 
Esto puede dar como resultado una página web, en formato legible 
por un aparato, que mantenga el significado del documento y sus di- 
versas partes. Si todas las notificaciones de coches a la venta se envia- 
ran usando el mismo formulario, entonces a los buscadores les sería 
fácil encontrar, exclusivamente, coches amarillos en Massachusetts. 
Éste es el sencillo primer paso para conseguir datos comprensibles 
por una máquina. 

El siguiente paso es un buscador que pueda aplicar la lógica para 
deducir si cada una de las muchas respuestas que consigue en una 
búsqueda inicial es útil. Esto nos permitiría hacer preguntas generales 
de nuestros agentes computerizados, como: “¿Jugó ayer algún equipo 
de baloncesto en un lugar en el que la temperatura fuera de 22%C?”. 
Un programa —llamémosle aparato lógico— aplicaría el razonamien- 
to matemático a cada objeto encontrado. El buscador podría encon- 
trar seis mil hechos relacionados con equipos de baloncesto, y dos mi- 
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llones de objetos con temperaturas y ciudades. El aparato lógico anali- 
zaría qué partes de los datos se refieren a dónde está un equipo de ba- 
loncesto, verifica qué temperatura hace en qué ciudades, filtra los dos 
juegos de datos, retira todo lo inservible y responde: “Los Red Sox ju- 
gaban en Boston ayer y la temperatura era de 22%C. Además, los 
Sharks jugaron en Tokio, donde hacía 222C”: Una búsqueda simple 
habría enviado una lista infinita de posibles respuestas en las que la 
persona tendría que rebuscar, Añadiendo la lógica, conseguimos la 
respuesta correcta. 

Mientras que las páginas web no están generalmente escritas para 
máquinas, hay una gran cantidad de datos en ellas, como citas de stock 
y muchas partes en catálogos en línea, con una semántica bien defini- 
da. Tomo como prueba de la urgente necesidad de un Web Semántico 
los muchos productos recientes de análisis de información no estructu- 
rada, como los usados por los brokers, para recuperar las páginas web 
normales y extraer los datos originales. Qué desperdicio: está claro que 
existe la necesidad de poder publicar y leer datos directamente. 

La mayoría de las bases de datos de uso diario son bases de datos 
relacionales; bases de datos con columnas de información que se rela- 
cionan unas con otras, como la temperatura, la presión barométrica y 
la localización en las bases de datos meteorológicas. Las relaciones en- 
tre las columnas son la semántica —el significado— de los datos. Es- 
tos datos están listos para ser publicados como página web semántica. 
Para que esto ocurra, necesitamos un lenguaje común que permita a 
los ordenadores representar y compartir datos, igual que el HTML 
permite a los ordenadores representar y compartir hipertexto. El con- 
sorcio está desarrollando un lenguaje así, el Resource Description Fra- 
mework [Estructura de Descripción de Recursos] (RDF), que, como 
es lógico, está basado en el XML. De hecho, no es más que XML con 
información acerca de qué bits son datos y cómo encontrar el signifi- 
cado de los datos. El RDF puede usarse en archivos dentro y fuera del 
Web. Puede también encajarse en páginas normales web HTML. La 
especificación RDF es relativamente básica y ya es una Recomenda- 
ción W3C. Lo que necesitamos ahora es un plan práctico para desple- 
garla. 

La primera forma de datos semánticos en el Web fueron los meta- 
datos: información acerca de información. (Hay una compañía llama- 
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da Metadata, pero yo uso aquí el término como nombre común, como 
se ha usado durante muchos años.) Los metadatos consisten en un 
conjunto de propiedades de un documento. Por definición, los meta- 
datos son datos, además de datos sobre datos. Describen información 
catalogada acerca de quién escribió páginas web y acerca de qué son; 
información acerca de cómo se relacionan páginas web como versio- 
nes, traducciones y reformateos; e información social como derechos 
de distribución y códigos de privacidad. 

La mayoría de las páginas web llevan ellas mismas unos cuantos 
bits de metadatos. Las páginas HTML tienen un espacio escondido en 
el documento donde ciertos objetos pueden ser codificados, como el 
título de la página, su autor, qué software se usó para crearla, cuándo 
fue creada, y cuándo fue modificada por última vez. Á menudo esto 
está dispuesto de manera orientada a las personas, en inglés normal, 
en la parte de abajo de una página web en letra pequeña. La informa- 
ción legal, como el propietario del copyright y la privacidad del editor, 
pueden también estar ahí. Los metadatos que ya circulan pueden in- 
cluir información catalogada, como palabras clave y números de clasi- 
ficación, y todas las cosas que las bibliotecas suelen poner en las fi- 
chas. Hay información de respaldo, como etiquetas PICS. Y hay una 
información estructural acerca de qué páginas web en un sitio actúan 
como página de portada, tabla de contenidos o índice. No hay fin para 
los metadatos, y un lenguaje RDF común debería formar con ellos un 
mundo consistente. 

La introducción del RDE no ha sido clara ni fácil, y se ha discutido 
mucho acerca de cómo debería ser introducido y hasta si debería ser- 
lo. Esto es porque, como muchos nuevos lenguajes, se enfrenta a un 
dilema básico inherente al diseño de cualquier lenguaje. El HTML es 
un lenguaje limitador: sólo puede usarse para expresar documentos 
de hipertexto. El Java, por el contrario, no lo es: se puede escribir en 
Java para hacer casí cualquier cosa. Los lenguajes limitadores son úti- 
les porque se puede, por ejemplo, analizar una página HTML elemen- 
to por elemento, convertirla en otros formatos, hacer un índice y cual- 
quier otra cosa. Está claro para qué es cada cosa. La gente hace todo 
tipo de cosas con las páginas HTML que no estaban previstas en un 
principio para esas páginas. Un applet Java es distinto. Como Java es 
un lenguaje de programación completo, el único modo de saber cómo 
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funcionará un applet Java es ponerlo en marcha y observar. Cuando 
diseñé el HTML para el Web, decidí evitar el darle más potencia de la 
absolutamente necesaria; un “principio de potencia menor” al que me 
he atenido desde entonces. Podía haber usado un lenguaje como el 
“TeX” de Donald Knuth que, aunque parece un lenguaje markup es 
de hecho un lenguaje de programación. Hubiera permitido una tipo- 
grafía de fantasía y todo tipo de truquitos, pero habría habido pocas 
posibilidades de convertir las páginas web en otra cosa. Habría permi- 
tido expresar absolutamente cualquier cosa en la página, pero tam- 
bién habría permitido páginas que pudieran hundirse, o girar para 
siempre. Ésta es la tensión. 

Hay cierto temor a que un día el gran hermano del RDF se con- 
vierta en un lenguaje de programación, y las fichas de la biblioteca em- 
piecen a componer música, y los cheques se hagan pagaderos a una 
persona cuyo nombre pueda calcularse sólo usando doscientos años 
de tiempo de ordenador. Se sabe que, al ver mis planes del Web Se- 
mántico, los científicos informáticos del MIT y los miembros del con- 
sorcio alzaron las cejas y sugirieron que deberíamos mantener baja la 
potencia del lenguaje total. ¿Deberíamos, entonces, evitar la presencia 
de lenguajes poderosamente descriptivos en el Web? 

La respuesta es que dentro de muchas aplicaciones del Web, de- 
beríamos hacerlo, pero en el Web como conjunto, no. ¿Por qué? Por- 
que cuando vemos la complejidad del mundo que el Web Semántico 
sería capaz de describir, nos damos cuenta de que debería ser posible 
usar cualquier cantidad de potencia que fuese necesaria. Una razón 
del éxito del Web es que el hipertexto es un medio tan flexible que el 
Web no tiene que encerrar la sabiduría que trata de representar. Lo 
mismo debe ocurrir también en el caso de la red de significados. De 
hecho, la red de todo lo que conocemos y usamos de día en día es 
compleja: necesitamos la fuerza de un lenguaje fuerte para represen- 
tarla. 

Aquí el truco, sin embargo, está en asegurarse de que cada parte 
mecánica limitada del Web, cada aplicación, está en su interior com- 
puesta de partes simples que nunca llegarán a ser demasiado potentes. 
En muchos lugares necesitamos la simplicidad transparente del 
HTML, de modo que cada aplicación, como una máquina ATM, fun- 
cione de una manera bien definida. El arte de diseñar aplicaciones en 
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el futuro consistirá en encajarlas en el nuevo Web en toda su compleji- 
dad, pero haciéndolas individualmente lo bastante sencillas para que 
funcionen cada vez de manera fiable. Sin embargo, el Web total de to- 
dos los datos de cada una de las aplicaciones de RDF crearán un mun- 
do muy complejo, en el que será posible preguntar preguntas incon- 
testables. Así es el mundo. La existencia de esas preguntas no hará 
que el mundo deje de girar, ni hará que les pasen cosas raras a los se- 
máforos. Pero abrirá una puerta a ciertas nuevas aplicaciones muy in- 
teresantes que rondan por el incalculable y amplio Web y, aunque no 
prometen nada, dan mucho. 


Para que una aplicación siga siendo simple, los documentos RDF pue- 
den ser limitados de modo que adopten sólo ciertas formas. Cada do- 
cumento RDF aparece con un puntero en la parte de arriba de su es- 
quema KDE, una lista maestra de los términos de datos usados en el 
documento. Cualquiera puede crear un nuevo documento de esque- 
ma. Hay en marcha dos lenguajes de esquema relacionados, uno para 
XML y uno para RDFE Entre ambos podrán hablarle a cualquier per- 
sona o programa acerca de los elementos de una página web que des- 
criban; por ejemplo, que el nombre de una persona es una ristra de ca- 
racteres pero que su edad es un número. Esto proporciona todo lo 
necesario para definir cómo se representan las bases de datos, y para 
empezar a hacer que todos los datos existentes estén disponibles. 
También proporcionan las herramientas para conservar el poder ex- 
presivo de un documento RDF limitado y que su comportamiento sea 
previsible. Nos permite soltar, poco a poco, el monstruo de un lengua- 
"je expresivo a medida que lo vamos necesitando. 

A medida que se va liberando potencia, los ordenadores que están 
en el Web Semántico consiguen en primer lugar la capacidad de des- 
cribir, luego de suponer, y más tarde de razonar. El esquema es un 
paso enorme que permitirá que haya una gran interoperabilidad y 
funcionalidad extra. Sin embargo, todavía no hace más que clasificar 
datos. No dice nada acerca de significado o comprensión. 

La gente “llega a un entendimiento común” consiguiendo un con- 
junto lo bastante parecido de asociaciones consistentes entre palabras. 
Eso permite a las personas trabajar juntas. Algunas cosas que conside- 
ramos verdades absolutas, como la verdad matemática que dice que 
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una línea recta está definida por dos puntos diferentes, son simples 
patrones. Otras cosas, como el que yo entienda la ira de alguien ante la 
injusticia, se basan en patrones complicados de asociaciones de cuya 
anatomía completa no somos totalmente conscientes. 

Cuando la gente “entiende” algo nuevo, significa que puede rela- 
cionarlo con otras cosas que ya han entendidorbien. Dos personas de 
diferentes planetas podrían establecer la diferencia entre rojo y azul 
haciendo cada uno un prisma y haciendo pasar la luz a través de él, y 
viendo qué color se desvía más lejos. Pero la diferencia entre amor y 
respeto sólo se acabaría entendiendo tras interminables discusiones. 
Igual que las palabras del diccionario, todo —hasta que amarramos 
las cosas al mundo físico— está definido en términos de otras cosas. 

Ésta es también la base del modo en que los ordenadores pueden 
“entender” algo. Aprendemos cosas muy sencillas —como asociar la 
palabra caliente con una sensación de quemazón— con una “progra- 
mación” temprana de nuestros cerebros. De igual modo, podemos 
programar un ordenador para que haga cosas sencillas, como un pago 
bancario, y luego decir tranquilamente que “entiende” un cheque 
electrónico. Alternativamente, un ordenador puede completar el pro- 
ceso siguiendo vínculos en el Web Semántico que le dicen cómo con- 
vertir cada término de un documento que no entiende en un docu- 
mento que entienda. Uso la palabra semántico para esa clase de forma 
relativamente procesable por la máquina de “significado”. El Web Se- 
mántico es la red de conexiones entre diferentes formas de datos que 
permiten a la máquina hacer algo que no podía hacer directamente. 

Esto puede sonar aburrido hasta que es aumentado proporcio- 
nalmente hasta llegar a la totalidad del Web. Imaginemos lo que los 
ordenadores pueden entender cuando hay un enorme revoltijo de 
términos y datos interconectados que pueden ser seguidos automáti- 
camente. El poder que tenemos en las puntas de los dedos sería tre- 
mendo. Los ordenadores “entenderían” en el sentido de que habrían 
logrado un aumento espectacular en su función al vincular muchos 
significados. 

Para construir entendimiento, necesitamos ser capaces de vincular 
términos. Los lenguajes de deducción permitirán que esto ocurra. Es- 
tos lenguajes funcionan a un nivel por encima de los lenguajes de es- 
quema. Los lenguajes de deducción permiten a los ordenadores expli- 
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carse unos a otros que dos términos que pueden parecer diferentes 
son en cierto modo lo mismo; un poco como un diccionario inglés-es- 
pañol. Los lenguajes de deducción permitirán a los ordenadores con- 
vertir datos de un formato en otro. 

Las bases de datos son producidas continuamente por diferentes 
grupos y compañías, sin conocimiento mutuo. Raramente alguien de- 
tiene el proceso para tratar de definir globalmente términos consisten- 
tes para cada una de las columnas que hay en las tablas de las bases de 
datos. Cuando podemos vincular términos, incluso muchos años des- 
pués, un ordenador podrá entender que lo que una compañía llama 
“temperatura media diurna” es lo mismo que lo que otra compañía 
llama “promedio de temperatura diurna”. Si el HTML y el Web hicie- 
ran que todos los documentos en línea parecieran un solo libro enor- 
me, el RDF y los lenguajes de esquema o deducción harían que todos 
los datos del mundo parecieran una enorme base de datos. 

Cuando disponemos de la capa de deducción, encontrar el coche 
amarillo a la venta se convierte en algo posible incluso aunque pre- 
guntemos por un automóvil amarillo. Cuando trata de rellenar un for- 
mulario de impuestos, mi ordenador que entiende el RDF puede se- 
guir vínculos hasta el esquema que el gobierno ha establecido para 
ello, encontrar punteros a las reglas y rellenar todas esas líneas por mí 
por deducción desde otros datos que ya conoce. 


Igual que con el actual Web, la descentralización es el principio de di- 
seño subyacente que dará al Web Semántico la capacidad de conver- 
tirse en algo más que la suma de sus partes. 

Ha habido muchos proyectos para almacenar significados inter- 
vinculados en un ordenador. El campo se ha llamado representación 
de conocimiento. Estos esfuerzos suelen usar sencillas definiciones ló- 
gicas, como las siguientes: un vehículo es una cosa, un coche es un ve- 
hículo, una rueda es una cosa, un coche tiene cuatro ruedas, etc., etc. 
Si se introducen las suficientes definiciones, un programa podría res- 
ponder preguntas siguiendo los vínculos de la base de datos y preten- 
der que piensa, de una manera mecánica. El problema es que esos sis- 
temas están diseñados alrededor de una base de datos central, que 
sólo tiene sitio para una definición conceptual de “coche”. No están 
diseñados para vincularse a otras bases de datos. 
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El Web, por el contrario, no trata de definir un sistema total, sino 
sólo una página web de cada vez. Cada página puede vincularse a to- 
das las demás. De manera semejante, el Web Semántico permitiría que 
diferentes sitios tuvieran su propia definición de “coche”. Podría ha- 
cerlo porque la capa de deducción permitiría a los aparatos vincular 
definiciones. Esto nos permite abandonar la necesidad de que dos 
personas tengan la misma idea rígida de lo que “es” algo. De este 
modo, la Comisión Europea podría establecer lo que cree que debe 
ser un formulario de impuestos. El gobierno estadounidense podría 
establecer su propio formulario de impuestos. Mientras la informa- 
ción esté en una forma que el aparato la pueda entender, un programa 
del Web Semántico podría seguir vínculos semánticos para deducir 
que la línea 2 en el formulario europeo es igual que la línea 3 A del for- 
mulario americano, que es como la línea 1 del formulario del estado 
de Nueva York. 

Supongamos que pido a mi ordenador que me dé una tarjeta co- 
mercial de Piedro, de Quadradynamics, pero no tiene ninguna. Puede 
buscar una factura a nombre de su compañía, la dirección y número 
de teléfono y sacar su dirección electrónica de un mensaje, y presentar 
toda la información necesaria que incluye una tarjeta comercial. Yo 
podría ser el primero en establecer esas relaciones entre los campos, 
pero ahora cualquiera que conozca los vínculos puede sacar una tarje- 
ta comercial de una factura enviada por e-mail. Si yo publico las rela- 
ciones, los vínculos entre campos, como RDE, entonces el Web Se- 
mántico en su totalidad conocerá la equivalencia. 

Perdonen los simplificados ejemplos, pero espero que el punto 
principal quede claro: los conceptos se vinculan. Cuando, finalmente, 
miles de formularios se vinculan a través del campo de “apellido” o 
“nombre de familia”, entonces cualquiera que analice el Web se dará 
cuenta de que ahí hay un importante concepto común. La cuestión es 
que nadie tiene que hacer este análisis. El concepto de “apellido” sen= 
cillamente empieza a surgir como una propiedad importante de una 
persona. Igual que un niño que está aprendiendo una idea gracias a 
frecuentes encuentros, el Web Semántico “aprende” un concepto a 
través de las contribuciones frecuentes de diferentes fuentes indepen- 
dientes. El Web hace esto sin apoyarse en el inglés ni en ningún len- 
guaje natural para entender. No traducirá poesía, pero traducirá fac- 
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turas, catálogos y material comercial, burocracia, viajes, impuestos y 
muchas más cosas. 

El razonamiento que hay detrás de esta reflexión es que no hay de- 
positario central de información, y ninguña autoridad sobre nada. 
Vinculando cosas, podemos llegar hasta muy lejos en el camino de la 
creación de un entendimiento común. El Web Semántico funcionará 
cuando los términos sé acuerden de manera general, cuando no lo 
sean, y más a menudo en el lío fractal de términos de la vida real que 
tienen diversos grados de aceptación, ya sean en oscuros campos o en 
culturas globales. 


Crear estándares globales es difícil. Cuanto más grande sea el mú- 
mero de personas involucradas, peor. En la actualidad, la gente 
puede trabajar junta con sólo unos pocos puntos de entendimiento 
globales, y muchos locales y regionales. Igual que con las leyes fede- 
rales e internacionales, y el Web, el principio de diseño minimalista 
nos dice: tratemos de constreñir lo menos posible para lograr un 
objetivo común. El comercio internacional funciona usando con- 
ceptos de comercio y pago. globales, pero no necesita que todo el 
mundo use la misma divisa, ni tenga las mismas penas por robo, y 
así sucesivamente, 

Cantidad de grupos aparte del W3C han descubierto lo difícil que 
es lograr un acuerdo global bajo la presión de las variaciones locales. 
Las bibliotecas usan un sistema llamado MARC, que es un modo de 
transmitir los contenidos de una tarjeta del catálogo de una biblioteca. 
Hace diez años se creó el Electronic Data Interchange [Intercambio 
de Datos Electrónicos] (EDD), para la práctica del comercio electróni- 
co, con equivalentes electrónicos estándar de cosas como formularios 
de encargo y facturas. En ninguno de los casos hubo un acuerdo total 
acerca de todos los campos. Se definieron algunos estándares, pero 
hubo en la práctica variaciones regionales o a nivel de compañía. Los 
procesos habituales de normalización nos dejaron ante el imposible 
dilema de si deberíamos hacer sólo acuerdos entre dos partes, de 
modo que una factura de Boeing y una factura de Airbus estén bien 
definidas pero sean bastante diferentes, o si deberíamos posponer el 
tratar de llevar acabo cualquier comercio electrónico hasta que defi- 
namos lo que es una factura globalmente. 
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El plan del Web Semántico es poder moverse fácilmente de una si- 
tuación a otra y trabajar en conjunto con una mezcla. Los espacios de 
nombres XML permitirán a los documentos trabajar en una mezcla 
de términos estándar globales y términos acordados localmente. Los 
lenguajes de deducción permitirán a los ordenadores traducir quizá 
no la totalidad de un documento, pero. sí lo suficiente como para per- 
mitir que se pueda trabajar en él. Operar sobre semejante “entendi- 
miento parcial” es fundamental, y lo hacemos todo el tiempo en el 
mundo no electrónico. Cuando alguien en Uruguay envía a un ameri- 
cano una factura, el receptor no la puede leer porque está en español, 
pero se imagina que es una factura porque tiene referencias al número 
de una orden de compra, la cantidad que hay que pagar y a quién pa- 
garla. Eso es suficiente para decidir que eso es algo que tiene que pa- 
gar, y que le permite pagarlo. Las dos entidades están operando con 
vocabularios superpuestos. La factura está de acuerdo con la emitida 
en Uruguay, y las facturas estadounidenses también, y hay concordan- 
cia suficiente entre ellas como para que se lleve a cabo la transacción. 
Esto ocurre sin necesidad de una autoridad central que diga cómo 
debe hacerse una factura. 

Mientras los documentos se creen dentro del mismo marco lógico, : 
como el RDE el entendimiento parcial será posible, Así es como los 
ordenadores funcionarán cruzando fronteras, sin que haya personas 
que tengan que verse para ponerse de acuerdo sobre cada término es- 
pecífico globalmente. 

Esto seguirá siendo un incentivo para que evolucionen los crite- 
rios, aunque podrán evolucionar con continuidad y no gracias a una 
serie de batallas. Una vez que, por ejemplo, una asociación industrial 
establece un criterio de metadatos para facturas, tarjetas comerciales, 
órdenes de compra, etiquetas de facturación y todos los demás for- 
mularios de comercio electrónico, entonces de pronto millones de 
personas y compañías con todo tipo de ordenadores, software y re- 
des podrán llevar a cabo negocios electrónicamente. ¿Quién decidirá 
cuál es el criterio para hacer una factura? No el Consorcio Web, Es- 
tos pueden opinar de diferentes formas, por medio de grupos ad hoc, 
compañías individuales o gente. Lo único que el Consorcio Web ne- 
cesita hacer es establecer los protocolos básicos que permitan defi- 
nirse las reglas de deducción, y cada sector especializado de vida es- 
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tablecerá los acuerdos comunes necesarios para hacer el trabajo por 
ellos. 

Quizá la más importante contribución del Web Semántico sea 
proporcionar una base para la futura evolución general del Web. Los 
dos objetivos originales del consorcio fueron ayudar a que el Web 
mantuviera la interoperatividad, y ayudar a mantener su “evolutivi- 
dad”. Sabemos lo que necesitamos para la interoperatividad. La evolu- 
tividad no era más que una consigna. Pero si el consorcio puede crear 
ahora un medio ambiente en el que los procesos de normalización se 
convierten en una propiedad del modo en que el Web y la sociedad 
trabajan juntos, entonces habrán creado algo que no sólo es mágico, 
sino capaz de convertirse en algo aún más mágico. 

El Web tiene que ser capaz de cambiar lentamente, paso a paso, 
sin que lo detengan y lo rediseñen a partir de cero. Esto ocurre no sólo 
con el Web, sino con las aplicaciones web: los conceptos, los aparatos 
y los sistemas sociales que están construidos sobre él. Pues, aunque el 
Web pueda cambiar, los aparatos que lo están utilizando cambiarán 
mucho más. Las aplicaciones que hay en el Web no se crean de repen- 
te. Evolucionan a partir de una pequeña idea y van creciendo hasta 
hacerse más fuertes y más complejas. 

Para concretar esta consigna, no hay más que poner como ejemplo 
la frustración tan frecuente que aparece cuando un procesador de tex- 
tos en versión 4 se encuentra con un documento en versión 5 y no 
puede leerlo. El programa lanza los brazos al cielo horrorizado ante 
semejante encuentro con el futuro. Se detiene, porque cree (de mane- 
ra bastante razonable) que no va a poder entender un lenguaje en ver- 
sión 5, que no se había inventado cuando se escribió el programa. Sin 
embargo, con los lenguajes de deducción, un documento en versión 5 
será “autodescriptivo”; Proporcionará un URI para el esquema de la 
versión 5, El programa en versión 4 puede encontrar el esquema y, 
vinculadas a él, reglas para convertir el documento en versión 5 en un 
documento en versión 4 siempre que sea posible. Lo único necesario 
es que el software de la versión 4 tiene que estar escrito de manera que 
pueda entender el lenguaje en el que están escritas las reglas. Este len- 
guaje de deducción RDF, pues, tiene que ser un estándar, 

Cuando dejamos libre la potencia del RDF de modo que nos per- 
mita expresar reglas de deducción, aún podemos forzarlo para que no 
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sea un lenguaje tan expresivo que asuste a la gente. Las reglas de de- 
ducción no tienen por qué tener un lenguaje de programación com- 
pleto. Serán analizables y separables, y no deberían presentar amena- 
za alguna. Sin embargo, para automatizar algunas tareas de la vida 
real, el lenguaje tiene que volverse más potente. 

Volviendo al formulario de impuestos, imaginemos que las ins- 
trucciones para rellenarlo están escritas en lenguaje de ordenador. Las 
instrucciones están llenas de sí y de pero. Incluyen aritmética y alterna- 
tivas. Una máquina, para poder seguir estas instrucciones, necesitaría 
una capacidad bastante grande de razonamiento. Tendría que discu- 
rrir qué poner en cada línea siguiendo vínculos para encontrar relacio- 
nes entre datos como estados de cuentas bancarios electrónicos, reci- 
bos y notas de gastos. 

¿Cuál es la ventaja de este punto de vista sobre, por ejemplo, un 
programa de preparación de impuestos, o simplemente abandonar y 
escribir un programa Java para hacerlo? La ventaja de poner las re- 
glas en RDF es que al hacerlo, todo el razonamiento queda expues- 
to, mientras que un programa es una caja negra: no se ve lo que 
ocurre dentro. Cuando usé un programa de impuestos para saber 
qué tenía que pagar en 1997, el programa se equivocó en la canti- 
dad final. Creo que se confundió entre los impuestos estimados pa- 
gados en 1977, y los pagados para 1997, pero nunca lo sabré con 
toda seguridad. El programa leyó toda mi información y rellenó el 
formulario incorrectamente. Yo no hice caso del resultado, pero no 
pude arreglar el programa porque no podía saber cómo funcionaba. 
El único modo de haber podido revisar el programa era haber he- 
cho el trabajo yo mismo a mano. Si un aparato razonador hubiera 
introducido todos los datos y deducido los impuestos, yo podría 
haberle preguntado por qué había hecho lo que había hecho, y co- 
rregir el origen del problema. 

Ser capaz de preguntar “¿Por qué?” es importante. Permite al 
usuario remontarse hasta las suposiciones que se hayan hecho y hasta 
las reglas y datos utilizados. Los aparatos razonadores nos permitirán 
manipular, descubrir, encontrar y demostrar cosas lógicas y numéricas 
en un campo completamente abierto de aplicaciones. Nos permitirán 
manejar datos que no entren en categorías claras, como “finanzas”, 
“planificación de viajes” o “calendario”. Y son esenciales para que 
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confiemos en los resultados en línea, porque nos dan la posibilidad de 
saber cómo se dedujeron los resultados. 


La desventaja de usar aparatos razonadores es que, como pueden 
combinar datos que estén por todo el Web mientras buscan respues- 
tas, puede ser fácil que hagamos una pregunta abierta que tenga como 
resultado una búsqueda sin fin. Incluso aunque tengamos reglas bien 
definidas en lo que se refiere a quién puede acceder al sitio web del 
consorcio, sólo para miembros, no puede uno acercarse a él y simple- 
mente pedir el acceso. Esto haría que el servidor web empezase una 
búsqueda abierta porque sí. No podemos permitir que nuestro servi- 
dor web pierda el tiempo haciendo eso; un usuario tiene que venir 
equipado con ciertas credenciales. Actualmente, a los usuarios se les 
pregunta según qué regla o a través de qué miembro tienen derecho 
de acceso. Un ser humano verifica la lógica. A nosotros nos gustaría 
hacerlo automáticamente. En esos casos necesitamos un formulario 
especial de RDF en el que se pueda incluir la explicación; si se quiere, 
una declaración con la respuesta a todos los porqués. Mientras que 
encontrar un buen argumento de por qué alguien debería tener acce- 
so puede suponer largas búsquedas, o conocimientos, o complejos ra- 
zonamientos, una vez que se haya encontrado ese razonamiento, veri- 
ficarlo es una cuestión mecánica que podemos dejar a una simple 
herramienta. Por eso es por lo que se necesita un lenguaje que trans- 
mita una prueba a través de Internet. Una prueba no es más que una 
lista de fuentes en las que buscar información, con indicadores a las 
reglas de deducción que se usaron para ir de un paso al siguiente. 

En la complejidad del mundo real, la vida puede seguir adelante 
incluso cuando existan preguntas que los aparatos razonadores no 
puedan contestar. No hacemos que asuntos fundamentales de nues- 
tros asuntos diarios dependan de que se puedan contestar o no. Pode- 
mos apoyar la colaboración con una infraestructura técnica que pueda 
respetar las necesidades de la sociedad en toda su complejidad. 

Naturalmente, el que creamos en determinados documentos de- 
penderá en el futuro de las firmas digitales de criptografía de clave 
pública. Un “aparato de confianza” (“trust engine”) será un aparato 
razonador con una ficha de firmas incluida que le dé una capacidad 
inherente para validar una firma. El aparato de confianza es el tipo de 
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agente más poderoso que hay en el Web Semántico. Ha habido pro- 
yectos en los que un aparato de confianza usaba un lenguaje menos 
potente, pero francamente creo que, mirando las cosas con realismo, 
vamos a necesitar un lenguaje muy expresivo para expresar auténtica 
confianza, y los aparatos de confianza capaces de entender dicho len- 
guaje. El truco que hará funcionar el sistema en la práctica será enviar 
explicaciones a todas partes en la mayoría de los casos, en lugar de es- 
perar que el receptor averigiúe por qué debería creerse determinada 
cosa. 

Crear la actual firma digital en un documento es la parte más sen- 
cilla de la tecnología de confianza. Puede hacerse sin tener en cuenta 
el lenguaje usado para crear el documento. Permite firmar un docu- 
mento, o parte de él, con una clave, y verificar que un documento ha 
sido firmado con una clave. La idea es que haya un modo estándar de 
firmar cualquier documento XML. El consorcio inició en 1999 esta 
actividad, combinando experiencias anteriores de firmas de etiquetas 
PICS con nuevas ideas procedentes del mundo bancario. 

La otra cara de la confianza, que en realidad teje el Web de la Con- 
fianza, es la madeja de declaraciones acerca de quién confía en las de- 
claraciones de qué forma cuando están firmadas con qué claves. Aquí 
es donde está el meollo del asunto, el reflejo real de la sociedad en la 
tecnología. Conseguir que esto funcione bien permitirá que ocurra de 
todo, desde colaboración entre dos personas hasta comercio entre 
corporaciones, y nos permitirá confiar realmente en que las máquinas 
están funcionando para nosotros. Á medida que el Web se use para re- 
presentar cada vez más lo que pasa en la vida, establecer una confian- 
za se va volviendo más complicado. Ahora mismo, la situación de la 
vida real es demasiado complicada para nuestras herramientas en 
línea. 

En la mayoría de nuestras vidas diarias, entonces, incluso en un 
mundo complejo, cada paso debería ser honrado. No tenemos que li- 
berar la potencia total del RDF para que nuestra tarea se realice. No 
hay necesidad de temer que el uso del RDF requiera que los ordena- 
dores se pongan a hacer conjeturas. 

Sin embargo, ahora que estamos considerando el más complejo de 
los casos, no debemos ignorar aquellos en los que los ordenadores tra- 
tan de dar respuestas razonablemente buenas a preguntas abiertas. 
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Las técnicas que usan son heurísticas; esto es, decisiones que se toman 
cuando no se pueden examinar todas las alternativas. Cuando una 
persona usa un buscador, y ve la primera página que le ofrece una pis- 
ta prometedora, está usando la heurística. Quizá mire los títulos, o las 
primeras líneas citadas, o los propios URI; en cualquier caso, usar la 
heurística es un arte adquirido. Los programas heurísticos de un ban- 
co son los que hacen sonar una alarma cuando el patrón de gastos de 
la tarjeta de crédito de una persona parece diferir del habitual. 

La interrelación entre los sistemas heurísticos y los estrictamente 
lógicos será interesante. La heurística hace suposiciones y la lógica las 
comprueba. Los robots recorrerán el Web y harán índices de ciertas 
formas de datos, y esos índices no llegarán a ser definitivos, pero serán 
tan buenos que se podrán usar como definitivos para muchos fines. La 
heurística puede llegar a ser tan buena que parezca perfecta. El Web 
Semántico está siendo cuidadosamente diseñado de manera que no 
tenga que responder a preguntas abiertas. Por eso es por lo que fun- 
cionará y crecerá. Pero al final también proporcionará una base a 
aquellos programas que puedan usar la heurística para emprender lo 
que antes era impensable. 

A partir de aquí es difícil predecir lo que ocurrirá en el Web Se- 
mántico. Como podremos definir límites de confianza, estaremos in- 
clinados, dentro de esos límites, a dar más potencia a las herramientas. 
Las técnicas como los virus o las cartas en cadena, que ahora conside- 
ramos destructivas, se convertirán en modos de conseguir que se reali- 
ce un trabajo. Usaremos la heurística y haremos preguntas abiertas 
sólo cuando hayamos hecho una sólida base de modos predecibles de 
contestar preguntas directas. Seremos brujos en nuestro nuevo mun- 
do cuando hayamos aprendido a controlar nuestras creaciones. 


Aunque el proyecto de las tecnologías necesarias para conseguir un 
nuevo Web no está claro como el cristal, la visión macroscópica que 
he presentado debería al menos permitirnos deducir que queda mu- 
cho trabajo por hacer. Parte de este trabajo queda aún lejano. Y parte 
no es aún más que un brillo en los ojos. 

A medida que el trabajo avanza, veremos de manera más precisa 
cómo encajan las piezas. Ahora mismo, la arquitectura final es hipoté- 
tica; estoy diciendo que podrían encajar, que deberían encajar. Cuan- 
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do trato de explicar la arquitectura ahora, la gente me mira con la mis- 
ma mirada distante con la que me miraban en 1989, cuando trataba de 
explicarles cómo funcionaría el hipertexto global. Pero he encontrado 
a unas cuantas personas que comparten la visión; lo veo por el modo 
en que gesticulan y hablan rápidamente. En esos raros casos también 
tengo la misma sensación en el estómago que tuve hace una década: 
trabajarán para quien tengan que trabajar, harán lo que sea necesario, 
para contribuir a que el sueño se haga realidad. Una vez más, va a ser 
un asunto fundamental. 

El proyecto del nuevo Web también se parece mucho a mi pro- 
puesta de 1989 para el Web original. Tiene una base social, un plan 
tecnológico y algo de filosofía básica. Unas cuantas personas lo entien- 
den; la mayoría no. Al principio escribí el código del World Wide 
Web, luego me lancé al mundo a promocionar la idea, hacer que la 
tecnología estuviera disponible para que la gente pudiera empezar a 
trabajar con esa pequeña parte, y les animé. 

Actualmente el consorcio podría escribir parte del código, o al 
menos coordinar la escritura del código. Quizá la comunidad infor- 
mática compartirá la visión y completará las piezas según un modelo 
comercial durante unos años. O quizá alguien que esté mirando desde 
fuera se dé cuenta de repente: “Sé cómo se puede hacer esto. No sé 
cómo inventar un modelo comercial, pero creo que puedo escribir el 
código en dos semanas”. 

Que diversas personas trabajaran en el primer Web fue algo que 
progresó de manera bastante coordinada porque yo había escrito el 
primer código, lo que daba a los demás algo sobre lo que escribir. 
Ahora tenemos dos herramientas que antes no teníamos. Una es el 
consorcio; un lugar en el que la gente puede reunirse así como un lu- 
gar donde encontrar avanzadas plataformas de software, como Jigsaw 
y Apache, que la gente puede utilizar para probar sus nuevas ideas. La 
segunda herramienta es el propio Web. Extenderse por el mundo será 
mucho más fácil. Yo puedo publicar este plan en el mundo entero 
cuando esté solamente a medio terminar. El modo normalmente aca- 
démico en que Robert Cailliau y yo pudimos difundir la propuesta 
original fue introducirlo en los debates de las conferencias de hiper- 
texto; y fue rechazada. Este proyecto no está listo para difundirse en 
forma de conferencia aún, y no me siento inclinado a hacer que lo 
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esté, Nos limitaremos a sacarlo afuera, de manera que la gente pueda 
verlo y hablar de él. Una vez que se ha plantado una semilla, conten- 
drá indicadores del lugar de donde viene, de modo que las ideas se 
propaguen mucho más rápidamente. 

Los cínicos ya me han dicho: “¿Crees de verdad que esta vez la 
gente va a pasarse horas y horas con el proyecto, como hicieron Pei 
Wei y todos los demás?”. Sí. Porque eso es precisamente lo que decían 
los cínicos en 1989. Decían: “Bueno, esto es demasiado”. Pero, re- 
cuerden, sólo se necesitan media docena de personas válidas en los lu- 
gares adecuados. Entonces, encontrar a esa docena de personas llevó . 
mucho tiempo. Actualmente no hay más que ir al consorcio, coger 
ideas y difundirlas. 

Ciertamente, esta vez el peligro es que tenemos seiscientas perso- 
nas creando aparatos razonadores en sus garajes. Pero si tratan de pa- 
tentar lo que están haciendo, creyendo cada uno que ha encontrado la 
gran solución el primero, o si construyen barreras de formatos de pro- 
piedad y usan modos peculiares y no documentados de hacer las co- 
sas, no harán más que estorbar. Si, a través del consorcio, vienen 
abiertamente a la mesa para hablar, todo esto puede funcionar bien 
muy pronto. 


Menciono las patentes de pasada, pero de hecho son un gran escollo 
para el desarrollo del Web. Los promotores dejan en espera sus es- 
fuerzos en una determinada dirección cuando oyen rumores de que 
alguna compañía puede tener una patente que tenga que ver con la 
tecnología. Actualmente, en Estados Unidos (contrariamente a mu- 
chos países), es posible patentar parte de la manera en que un progra- 
ma hace algo. Esto es en cierto modo como patentar un procedimiento 
comercial: es difícil definir lo que es realmente “nuevo”. Ciertamente, 
entre algunas patentes que he revisado, me ha parecido difícil encon- 
trar algo que me dé una sensación de idea nueva. Algunas no hacen 
sino coger un proceso ya conocido (como los préstamos entre biblio- 
tecas O las apuestas en las carreras) y lo hacen en software. Otros com- 
binan conocidas técnicas de modos aparentemente arbitrarios sin 
efecto añadido alguno; como patentar el ir de tiendas en un coche de 
rayas los jueves. Pasan la prueba de la aparente novedad porque no 
hay documento que describa exactamente un proceso así. En 1980, un 
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dispositivo para entregar un libro electrónicamente, o un dispositivo 
para apostar en línea podrían resultar novedosos, pero ahora esas co- 
sas no son más que versiones web obvias de cosas bien conocidas. La 
Oficina de Patentes y Marcas Registradas de Estados Unidos, mal 
equipada para buscar “arte:prioritario” (la primera ocurrencia de una 
misma idea) en este nuevo campo, parece haber solucionado la cosa 
concediendo patentes por defecto. 

Es a menudo difícil saber de qué es una patente porque está es- 
crita de manera oscura usando un lenguaje bastante diferente del 
que un programador normal usaría. Hay una razón para esto: el 
arma es el miedo a un pleito, más que la patente en sí. Las compañías 
adquieren los derechos de patentes unas de otras sin establecer si- 
quiera lo que esas patentes significan en realidad. El miedo aumenta 
por la incertidumbre y la duda, por lo que hay un incentivo para ser 
oscuro. Sólo los tribunales pueden determinar lo que significa una 
patente, y el esfuerzo legal y el tiempo empleados empequeñece el 
esfuerzo técnico. 

Este ambiente es nuevo. Las patentes de software son nuevas. El 
espíritu de Internet en los setenta y ochenta consistía en compartir 
para el bien común, y habría sido impensable para un participante pe- 
dir tasas sólo por aplicar un protocolo estándar como el HTTP. Ahora 
las cosas están cambiando. Las grandes compañías acumulan patentes 
como amenaza de represalias ante demandas de sus semejantes. A las 
pequeñas compañías les aterroriza entrar en el negocio. 

El señuelo de conseguir un trozo de alguna parte fundamental de 
la nueva infraestructura es grande. Algunas compañías (e incluso indi- 
viduos) se ganan la vida sacando patentes y demandando a compañías 
más grandes, inmunizándose contra las represalias porque en realidad 
no hacen ni venden ningún producto. El objetivo original de las pa- 
tentes —fomentar la publicación y despliegue de ideas y proteger los 
incentivos para investigación— es noble, pero el abuso es ahora un 
problema muy serio. 

Actualmente la tendencia parece ser que las patentes son cuestión 
de lo que se pueda sacar de ellas. Los ingenieros, a los que los aboga- 
dos de una compañía les piden que proporcionen ideas patentables 
cada pocos meses, entregan resignadamente “ideas” que hacen estre- 
mecerse a los propios ingenieros. 
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Es tiempo de que haya un cambio, hacia un espíritu en el que las 
compañías usen patentes para defender sus propios productos váli- 
dos, en lugar de hacer demandas oportunistas sin sentido. El umbral 
de la “innovación” está demasiado bajo. Los abogados de las empre- 
sas están enquistados-en la costumbre de discutir cualquier ventaja 
que puedan, y probablemente sólo un liderazgo empresarial determi- 
nado podría poner de nuevo a la industria en el buen camino. Los 
miembros del consorcio, en el momento de escribir esto, están discu- 
tiendo qué hacer, pero todavía no está claro cuál será el resultado. 

El Web Semántico, como ya hace el Web, hará que muchas cosas 
que antes eran imposibles se conviertan en obvias. Mientras escribo 
sobre nueva tecnología, me pregunto si será un sueño técnico o una 
pesadilla legal. 


14. TEJIENDO LA RED 


¿Podrá el futuro Web cambiar el modo en que la gente trabaja junta 
y aumenta sus conocimientos en una pequeña empresa, en una gran 
organización, en un país? Si funciona para un pequeño grupo y pue- 
de aumentar proporcionadamente, ¿puede usarse para cambiar el 
mundo? Sabemos que el Web nos permite hacer cosas más rápida- 
mente, pero ¿puede hacer un cambio de fase en la sociedad, un 
avance hacia una nueva manera de trabajar? ¿Y eso será para mejor 
O para peor? 

En una empresa con seis empleados, todo el mundo se puede sen- 
tar alrededor de una mesa, compartir sus opiniones y llegar a un 
acuerdo acerca de todos los términos que están usando. En una gran 
empresa, alguien define los términos comunes y el comportamiento 
que hace que la compañía funcione como una entidad. Aquellos que 
han pasado por esa transición lo saben muy bien: normalmente des- 
truye la diversidad. Es una estructura demasiado rígida. Y a medida 
que la empresa crece, los límites burocráticos cortan cada vez más sus 
comunicaciones internas, su fluido vital. En el otro extremo está la co- 
munidad utópica sin estructura, que tampoco funciona, porque nadie 
saca la basura. 

El que un grupo pueda avanzar depende de crear la conexión ade- 
cuada entre la gente; ya sea en una familia, en una compañía, en un 
país o en el mundo. Hemos estado tratando de averiguar cómo crear 
esto durante años. En muchas formas, no hemos tenido que decidir, 
ya que la geografía ha decidido por nosotros. Las compañías, y las na- 
ciones, han estado siempre definidas por una agrupación física de per- 
sonas. La estabilidad militar de una nación estaba basada en los em- 
plazamientos de tropas y las distancias de marcha. La diversidad de 
culturas que hemos tenido también ha surgido de un espacio bidi- 
mensional. La única razón por la que la gente de un pequeño pueblo 


186 Tejiendo la Red 


de Suiza hable un dialecto único es porque estaban rodeados de mon- 
tañas. La geografía dio al mundo su estabilidad militar y sus sectores 
culturales. La gente no tenía que decidir cómo de grandes tenían que 
ser sus grupos o dónde colocar los límites. Ahora que la medida no 
son las distancias físicas, ni siquiera las zonas horarias, sino los clics, 
tenemos que tomar esas decisiones. Internet y el Web nos han sacado 
del espacio bidimensional. También nos han quitado de la cabeza la 
idea de que no vamos a ser interrumpidos por nadie que esté a más de 
un día de distancia andando. 

Al principio, esta violación de nuestras reglas largo tiempo esta- 
blecidas puede ser inquietante, destruyendo un sentido geográfico de 
identidad. El Web rompe los límites en los que confiábamos para defi- 
nirnos y protegernos, pero también puede crear límites nuevos. 

Lo que no aumenta proporcionalmente cuando una compañía 
crece es la intuición: la capacidad para resolver problemas sin usar un 
método lógico bien definido. Una persona o grupo pequeño pensan- 
do en voz alta, medita acerca de problemas hasta que surgen posibles 
soluciones. Las respuestas no llegan necesariamente por seguir una 
senda lógica, sino más bien viendo dónde pueden conducir las cone- 
xiones. Una compañía más grande no consigue ser intuitiva cuando la 
persona que tiene la respuesta no está hablando con la persona que 
tiene la pregunta. 

Es importante que el Web ayude a la gente a ser intuitiva además 
de analítica, porque nuestra sociedad necesita ambas funciones. Los 
seres humanos tienen un equilibrio natural cuando usan las partes 
creativa y analítica de su cerebro. Resolveremos grandes problemas 
analíticos utilizando la potencia informática del Web Semántico. 

Aumentar la intuición es difícil porque nuestras mentes mantie- 
nen miles de asociaciones tentativas efímeras al mismo tiempo. Para 
dar lugar a una intuición de grupo, el Web debería poder capturar 
esos hilos: pensamientos a medias que surgen, sin un pensamiento ra- 
cional evidente o una deducción, a medida que trabajamos. Tendría 
que poder presentarlos a otro lector como complemento natural de 
una idea a medio formar. El paso intuitivo tiene lugar cuando alguien 
que está siguiendo vínculos de varias personas independientes se da 
cuenta de que hay una relación importante entre todas, y crea un atajo 
para registrarla. 
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Todo esto funciona sólo cuando cada persona forma vínculos 
mientras navega, por lo que escribir, crear vínculos y navegar debe ser 
algo totalmente integrado. Si alguien descubre una relación pero no 
hace el vínculo, él o ella sabrán más, pero el grupo no. 

Para crear ese atajo, una persona tiene que tener dos objetos de 
deducción en la cabeza al mismo tiempo. El nuevo Web hará que sea 
mucho más probable que alguien en alguna parte esté mirando en 
una fuente que contenga la mitad de la idea clave, y resulte que aca- 
ba de mirar recientemente la otra. Para que esto sea posible, el Web 
tiene que estar bien conectado, tener varios “grados de separación”. 
Éste es el tipo de cosa que los investigadores están siempre tratando 
de hacer: conseguir meterse el máximo posible en la cabeza, luego ir 
a dormir, despertarse en mitad de la noche con una brillante idea y 
correr a ponerla por escrito. Pero a medida que el problema crece, 
queremos ser capaces de enfocar la cuestión a una escala mucho ma- 
yor. Tenemos que estar seguros de que diseñamos el Web para per- 
mitir el feedback a partir de la gente que ha creado nuevos vínculos 
intuitivos. 

Silo logramos, la creatividad surgirá entre grupos mayores y más 
diversos. Estas actividades de alto nivel, que han. tenido lugar dentro 
de un solo cerebro humano, surgirán en grupos incluso más grandes, 
más interconectados, que actúen como si compartiesen un cerebro in- 
tuitivo mayor. Es una analogía intrigante. Quizá esa actividad noctur- 
na no sea después de todo una pérdida de tiempo: no es más que el 


sueño del Web. 


Los átomos tienen cada uno una valencia: la capacidad para conectar 
con otros tantos átomos. Como individuo, cada uno de nosotros reco- 
ge unos cuantos canales en los que participar, y podemos arreglárnos- 
las sólo con unos cuantos. La ventaja de conseguir que las cosas se ha- 
gan más rápidamente en el Web es una ventaja sólo hasta el punto en 
que podamos aceptar la información más deprisa, y haya límites defi- 
nidos. Aumentando un poco todo lo que tenemos que leer y escribir, 
el número de e-mails al que nos enfrentamos y el número de sitios 
Web que tenemos que recorrer, podemos reunir unos cuantos bytes 
más de conocimientos, pero nos agotaremos en el proceso y no iremos 
al grano. 
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A medida que los grupos van trabajando juntos, los miembros em- 
piezan a alcanzar un entendimiento común que incluye nuevos con- 
ceptos, que sólo ellos comparten. A veces esos conceptos pueden lle- 
gar a ser tan sólidos que el grupo descubre que tiene que luchar con el 
resto del mundo para explicar sus decisiones. En este punto, los 
miembros pueden darse cuenta por primera vez.de que han empezado 
a usar palabras de formas especiales. Puede que no se den cuenta de 
cómo han formado una pequeña subcultura hasta que empiezan a ex- 
plicar sus decisiones a colegas que están fuera del grupo. Han cons- 
truido un nuevo entendimiento, y al mismo tiempo construido una 
barrera a su alrededor. Los límites del entendimiento se han roto, pero 
se han formado otros nuevos alrededor de aquellos que comparten un 
huevo concepto. 

Se ha hecho una elección, y hay ganancias y pérdidas en términos 
de entendimiento compartido. 

¿Qué es lo que debe guiarnos cuando hacemos esas elecciones? 
¿Qué tipo de estructura pretendemos, y qué principios nos ayudarán 
a lograrlo? El Web es un medio tan flexible que deja la decisión en 
nuestras manos. Del mismo modo que podemos seleccionar los víncu- 
los que hacemos individualmente, tenemos opciones en las máquinas 
sociales que creamos, las diversas piezas de nuestro juego de construc- 
ción. Sabemos que queremos una estructura bien conectada de intui- 
ción de grupo para trabajar. Sabemos que debe estar descentralizada, 
ser elástica y justa. 

El cerebro humano supera a los ordenadores por su increíble nivel 
de procesamiento paralelo. La sociedad, de igual modo, resuelve sus 
problemas en paralelo. Para que la sociedad funcione eficazmente en 
el Web, se requiere un paralelismo masivo. Todo el mundo tiene que 
poder publicar, y controlar quién tiene acceso a sus trabajos publica- 
dos. No debe haber una estructura (como un sistema de autopistas o 
un sistema decimal Dewey obligatorio) ni una limitación que imposi- 
bilite cualquier tipo de idea o solución sólo porque el Web no vaya a 
permitir que se explique. 

Antes de que existiera el Web, Internet florecía en una arquitectu- 
ra técnica descentralizada y una arquitectura social descentralizada. 
Éstas fueron creadas incrementalmente por el diseño de una maqui- 
naria técnica y social. La comunidad tenía suficientes reglas de com- 
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portamiento para funcionar usando las sencillas máquinas sociales 
que inventaba. Empezó a partir de un mundo plano en el que cada or- 
denador no tenía más que una dirección de Internet y todo el mundo 
se consideraba igual, pero con el tiempo las oleadas de personas char- 
lando impusieron algo de orden. Los grupos de noticias dieron una 
estructura a la información y a la gente. El Web empezó con una falta 
similar de estructura preestablecida, pero pronto toda clase de listas 
de sitios “mejores” crearon una estructura basada en la competitivi- 
dad incluso antes de que se introdujera la publicidad. Mientras que el 
propio Internet parecía ser algo alejado de la jerarquía, sin jerarquía 
había demasiados grados de separación para evitar que las cosas se 
reinventaran: parecía haber una búsqueda de algo que no fuera un ár- 
bol, pero tampoco un espacio plano. 

Sin duda necesitamos una estructura que evite esas dos catástro- 
fes: la monocultura del uniforme global de McDonald's, y los aislados 
cultos de la Puerta del Cielo que no se entienden más que a sí mis- 
mos. Si cada uno de nosotros extiende su atención de manera igual 
entre grupos de diferentes tamaños, desde lo personal a lo global, 
ayudamos a evitar esos extremos. Vínculo a vínculo construimos sen- 
das de entendimiento a través de la red de la humanidad. Somos los 
hilos que cohesionan el mundo. Cuando hacemos esto, acabamos te- 
niendo de manera natural unos cuantos sitios web muy demandados, 
y una continua disminución de la enorme cantidad de sitios con muy 
pocos visitantes. En otras palabras, por muy atractiva que pueda pa- 
recer la igualdad entre pares, semejante estructura no es Óptima por 
su uniformidad. No presta la suficiente atención a la coordinación 
global, y puede requerir muchos clics para ir desde el problema a la 
solución. 

Si en lugar de ello todo el mundo divide su tiempo más o menos de 
manera igual entre los diez mejores sitios del Web, el resto de los cien 
mejores, el resto de los mil mejores, y así sucesivamente, la carga en di- 
versos servidores tendrá una distribución de tamaños característica de 
patrones “fractales” tan comunes en la naturaleza (desde las líneas de 
costa hasta los helechos) y del famoso patrón matemático “juego de 
Mandelbrot”. Resulta que algunas medidas de todo el tráfico en el 
Web de los empleados de Digital Equipment en la costa oeste reveló 
muy aproximadamente esta regla 1/1: el Web muestra propiedades 
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fractales incluso aunque no podamos ver individualmente los patro- 
nes, e incluso aunque no haya un sistema jerárquico para sostener se- 
mejante distribución. 

Esto no responde a la pregunta, pero es intrigante porque sugiere 
que hay dinámicas a gran escala funcionando para producir semejan- 
tes resultados. Jon Kleinberg, un científico informático de la Universi- 
dad de Cornell, descubrió un resultado fascinante: que cuando la ma- 
triz del Web se analiza como un sistema de mecánica cuántica, los 
estados de energía estables corresponden a conceptos que se están 
discutiendo. El Web está empezando a desarrollar estructuras a gran 
escala a su modo. Quizá podamos producir nuevas métricas para 
comprobar el progreso de la sociedad hacia lo que consideramos 
aceptable. 


La analogía del cerebro global es tentadora, porque tanto el Web 
como el cerebro incluyen un gran número de elementos —neuronas y 
páginas web— y una mezcla de estructura y aparente aleatoriedad. Sin 
embargo, un cerebro tiene una inteligencia que surge a niveles bastan- 
te diferentes a partir de cualquier cosa de la que pueda ser consciente 
una neurona. Desde Arthur C. Clarke hasta Douglas Hofstader, los 
escritores han observado una “propiedad emergente” que surge de la 
masa de la humanidad y de los ordenadores. Pero recordemos que se- 
mejante fenómeno tendría su propio orden del día. No seríamos cons- 
cientes de ello en tanto que individuos, y menos aún podríamos con- 
trolarlo, igual que la neurona no puede controlar al cerebro. 

Espero que haya propiedades emergentes con el Web Semántico, 
pero a un nivel menor que inteligencia emergente. Podría haber un 
orden o una inestabilidad espontáneos: la sociedad podría hundirse, 
igual que el mercado de valores se hundió en octubre de 1987 a causa 
de una operación monetaria automática hecha por ordenador. La fina- 
lidad del comercio —hacer dinero en cada operación no cambió—, 
pero la dinámica sí; se operó tan rápidamente con bloques de acciones 
tan enormes que el sistema entero se volvió inestable. 

Para asegurar la estabilidad, cualquier sistema electrónico com- 
plejo requiere un mecanismo de amortiguación para evitar que oscile 
de manera exagerada. Á partir de entonces se introdujeron mecanis- 
mos de amortiguación en el sistema de la bolsa. Podríamos instalarlos 


Tejiendo la Red 191 


en el Web Semántico para los ordenadores que cooperan pero ¿po- 
dríamos instalarlos en la red de personas que cooperan? La atención 
de la gente, el seguimiento de vínculos y el flujo de dinero ya están en- 
trelazados inextricablemente. 

Sin embargo, yo no baso mis esperanzas en un orden superpo- 
deroso. que surja espontáneamente del caos. Me parece que cons- 
truir deliberadamente una sociedad, de manera incremental, usando 
las mejores ideas que tengamos, es nuestro deber y debería ser tam- 
bién lo más divertido. Estamos aprendiendo poco a poco el valor 
que tienen sistemas descentralizados y diversos, y el mutuo respeto 
y la tolerancia. Ya sea que lo achaquemos a la evolución o a nuestro 
espíritu favorito, la cuestión es que parece ser que, en tanto que hu- 
manos, nos gusta al final sacar la mayor diversión de hacer lo “co- 
rrecto”, 

Mi esperanza y fe de que estemos dirigiéndonos a algo surge en 
parte de la observación repetidamente demostrada de que la gente 
parece estar naturalmente hecha para interactuar con otros como 
parte de un sistema más grande. Una persona que sea completamen- 
te introvertida, que pasa la mayor parte del tiempo sola, es alguien 
que tiene dificultades para tomar decisiones equilibradas y es muy 
infeliz. Alguien completamente extrovertido, que se preocupa del 
medio ambiente y la diplomacia internacional, y pasa poco tiempo 
sentado en casa o en su comunidad local, también tiene dificultades 
en tomar decisiones equilibradas y también es muy infeliz. Parece ser 
que la felicidad de una persona depende de un equilibrio de cone- 
xiones a diferentes niveles, Al parecer hemos construido en nuestro 
interior lo que una persona necesita para formar parte de una socie- 
dad fractal. 

Si acabamos produciendo una estructura en el hiperespacio que 
nos permita trabajar juntos armoniosamente, eso sería una metamor- 
fosis. Aunque, espero, tendría lugar de manera incremental, tendría 
como resultado una gran reestructuración de la sociedad. Una socie- 
dad que pudiera avanzar gracias a la intercreatividad y la intuición de 
grupo, en lugar del conflicto como mecanismo básico, sería un cam- 
bio muy importante. 

Si establecemos las bases e intentamos nuevas formas de interac- 
tuar en el nuevo Web, podemos encontrar todo un conjunto de es- 
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tructuras financieras, éticas, culturales y gubernamentales a las que 
podemos querer pertenecer, en lugar de escoger aquellas en las que ya 
vivimos físicamente. Poco a poco las estructuras que funcionen mejor 
serán más importantes en el mundo, y los sistemas democráticos pue- 
den tomar diferentes formas. 

Trabar juntos es la cuestión de encontrar entendimientos compat- 
tidos pero teniendo cuidado de no etiquetarlos como absolutos. Pue- 
den ser compartidos, pero a menudo serán arbitrarios en la imagen 
más grande. 

Pasamos mucho tiempo tratando de fijar significados y luchando 
para que nuestro marco de trabajo sea adoptado por otros. Es, des- 
pués de todo, un proceso de toda una vida el establecer conexiones 
con todos los conceptos que usamos. Un talento impresionante de mi 
tutor de física, el profesor John Moffat, consistía en que, cuando yo le 
llevaba un problema que había resuelto incorrectamente usando una 
extraña técnica y símbolos diferentes de los ya establecidos, no sólo 
seguía mi extraño razonamiento para descubrir qué era lo que estaba 
mal, sino que usaba entonces mis extrañas anotaciones para explicar 
la respuesta correcta. Esta gran proeza suponía mirar el mundo usan- 
do mis definiciones, compararlas con las suyas y traducir sus conoci- 
mientos y experiencia a mi lenguaje. Era una versión matemática del 
arte de escuchar. Este tipo de esfuerzo es necesario cada vez que se en- 
cuentra un grupo. También es el trabajo más difícil de los grupos de 
trabajo del consorcio. Aunque a menudo no es lo más apetecible, es lo 
que luego merece los parabienes. 

Tenemos que estar preparados para descubrir que la verdad “ab- 
soluta” con la que estábamos tan cómodos dentro de un grupo, se 
cuestiona de pronto cuando nos encontramos con otro grupo. La co- 
municación humana aumenta proporcionalmente sólo si podemos ser 
tolerantes con las diferencias mientras trabajamos con un entendi- 
miento parcial. 

El nuevo Web debe permitirme aprender cruzando límites. Tiene 
que ayudarme a reorganizar los vínculos que hay en mi propio cerebro 
para que pueda entender los que hay en el de otra persona. Tiene que 
permitirme mantener las estructuras que ya tengo, y relacionarlas con 
otras nuevas. Mientras tanto, en tanto que personas tenemos que 
acostumbrarnos a ver como comunicación y no como discusión las 
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conversaciones y desafíos que son parte necesaria de este proceso. 
Cuando fracasamos, tenemos que imaginar que se ha roto alguna es- 
tructura, o si no somos lo bastante listos para relacionar unas estructu- 
ras con otras. 


El paralelismo entre diseño técnico y principios sociales se ha repetido 
en toda la historia del Web. Un año después de que consiguiese poner 
en marcha el consorcio, mi esposa y yo descubrimos el Universalismo 
Unitario. Entrar en una iglesia Universalista Unitaria más o menos por 
azar nos pareció un soplo de aire fresco. Parte de las filosofías básicas 
de la asociación tiene mucho que ver con lo que yo he llegado a creer, 
y el objetivo con el que creé el Web. Está claro que el Universalismo 
Unitario no tuvo influencia alguna sobre el Web. Pero me doy cuenta 
de cómo pudo haberlo hecho, porque diseñé ciertamente el Web alre- 
dedor de principios universalistas (con 4 minúscula). 

Una de las cosas que me gustan del Unitarianismo es su falta de 
trampas religiosas, milagros y pompa y circunstancia. Es en cierto 
modo minimalista. Los unitaristas aceptaron las partes útiles de la filo- 
sofía de todas las religiones, incluyendo el cristianismo y el judaísmo, 
pero también el hinduismo, el budismo y cualquier otra filosofía, y las 
envolvieron no en una religión sólida, sino en un medio en el que la 
gente piensa y discute, conversa y trata siempre de aceptar las diferen- 
cias de opinión e ideas. 

Supongo que mucha gente no clasificaría el “U-Uísmo” como una 
religión en absoluto, porque no tiene dogma, y es muy tolerante con 
las diferentes formas de creer. Pasa la prueba de Invención Indepen- 
diente que aplico a los diseños técnicos: si algún otro hubiera inventa- 
do lo mismo independientemente, los dos sistemas deberían funcio- 
nar juntos sin que nadie tuviera que decidir cuál era el principal. Para 
mí, que disfrutaba de la aceptación y la diversidad de Internet, la igle- 
sia Unitarianista estaba muy bien. Las relaciones de igual a igual se fo- 
mentan cada vez que son oportunas, igual que el World Wide Web fo- 
menta que se haga un vínculo de hipertexto cada vez que es oportuno. 
Ambas son filosofías que permiten que se desarrollen sistemas des- 
centralizados, ya sean sistemas de ordenadores, de conocimientos o 
de personas. La gente que creó Internet y el Web aprecian de verdad 
el valor de los individuos y el valor de sistemas en el que los individuos 
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juegan su papel, con un sentido firme de su propia identidad y un sen- 
tido firme del bien común. 

Hay una libertad en el mundo de Internet: mientras aceptemos las 
reglas necesarias para enviar paquetes, podemos enviar paquetes que 
contengan cualquier cosa a cualquier parte. En el Universalismo Uni- 
tario, si uno acepta el principio básico del respeto mutuo para trabajar 
juntos hacia un objetivo importante, uno encuentra una enorme liber- 
tad para escoger palabras propias que capturen ese objetivo, rituales 
propios que ayuden a centrar la mente, metáforas propias que propor- 
cionen fe y esperanza. 

Tuve mucha suerte al trabajar en el CERN, por estar en un medio 
que tanto los Universalistas Unitarios como los físicos apreciarían 
igualmente: un ambiente de respeto mutuo y que construye algo muy 
grande por medio del esfuerzo colectivo que estaba mucho más allá de 
los medios de una sola persona, sin necesidad de un gigantesco régi- 
men burocrático. El medio era complejo y rico; cualquier par de per- 
sonas podía reunirse e intercambiar ideas, e incluso acabar trabajando 
juntos de algún modo. Este sistema produjo una extraña y maravillosa 
máquina, que necesitaba cuidados para mantenerse, pero que podía 
aprovecharse de la ingenuidad, inspiración e intuición de los indivi- 
duos de una manera muy especial. Éste fue desde el principio mi obje- 
tivo para el World Wide Web. 


La esperanza en la vida procede de las interconexiones entre todas las 
personas del mundo. Creemos que si todos trabajamos por aquello en 
lo que creemos individualmente que es bueno, entonces como con- 
junto conseguiremos más fuerza, más comprensión, más armonía a 
medida que seguimos el viaje. No encontramos al individuo subyuga- 
do por el todo. No encontramos las necesidades del todo subyugadas 
por el creciente poder de un individuo. Pero podemos ver más enten- 
dimiento en las luchas entre esos extremos. No esperamos que el siste- 
ma llegue a ser perfecto. Pero nos sentimos cada vez mejor acerca de 
ello. El viaje nos parece cada vez más excitante, pero no esperamos 
que acabe. 

¿Deberíamos entonces sentir que nos estamos volviendo cada 
vez más listos, que cada vez controlamos mejor la naturaleza, a me- 
dida que evolucionamos? En realidad, no. Sólo estamos mejor co- 
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nectados; conectados en mejor forma. La experiencia de ver el des- 
pegue del Web gracias al esfuerzo fundamental de miles de personas 
me da la enorme esperanza de que si tenemos la voluntad individual 
suficiente, podemos hacer colectivamente de nuestro mundo lo que 
queramos. 


APÉNDICE 


GESTIÓN DE INFORMACIÓN: UNA PROPUESTA 


Tim BERNERS-LEE, CERN 
Marzo 1989, mayo 1990 


Esta propuesta se refiere a la gestión de información general sobre acelera- 
dores y experimentos en el CERN. Habla del problema de pérdida de infor- 
mación sobre sistemas complejos evolutivos y propone una solución basada 
en un sistema de hipertexto distribuido. 
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VISIÓN GENERAL 


Muchas de las discusiones acerca del futuro en el CERN y de la era: del 
LHC acaban con la pregunta: “Sí, pero ¿cómo vamos a poder seguirle la 
pista a un proyecto tan grande?”. Esta propuesta proporciona una res- 
puesta a esa pregunta. En primer lugar, habla del problema del acceso a la 
información en el CERN. A continuación, introduce la idea de sistemas 
de información vinculada, y los compara con maneras menos flexibles de 
encontrar información. 

Finalmente resume mi corta experiencia con sistemas de texto no li- 
neal conocidos como “hipertexto”; describe lo que el CERN necesitaría 
de un sistema así, y de lo que puede proporcionar la industria. Y para ter- 
minar, sugiere los pasos que deberíamos dar para comprometernos ahora 
con el hipertexto, de manera que, individual y colectivamente, podamos 
entender lo que estamos creando. 


PÉRDIDA DE INFORMACIÓN EN EL CERN 


El CERN es una organización maravillosa. Está formada por varios miles 
de personas, muchas de ellas creativas, que trabajan todas con un objetivo 
común. Aunque están nominalmente organizadas en una estructura de 
gestión jerárquica, esto no limita el modo en que la gente se puede comu- 
nicar y compartir información, equipo y softwate entre los grupos. 

La estructura de trabajo que se observa actualmente de la organiza- 
ción es una red multiconectada cuyas interconexiones evolucionan con el 
tiempo. En este ambiente, cada vez que una nueva persona llega o alguien 
se hace cargo de una nueva tarea, se les suele decir con quién deben co- 
municarse. La información acerca de las instalaciones existentes y cómo 
encontrarlas viaja por los pasillos y a veces por carta, y los detalles acerca 
de lo que es necesario hacer se difunden de manera similar. Teniendo en 
cuenta todo esto, el resultado es bastante bueno, a pesar de que a veces 
haya malentendidos y se tengan que duplicar los esfuerzos. 

Sin embargo, el gran tránsito constante de gente es un problema. La 
información se está perdiendo todo el tiempo, ya que la estancia media de 
las personas es de dos años. La introducción de nuevas personas exige 
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una buena cantidad de su tiempo y del de los demás antes de que los nue- 
vos tengan alguna idea de lo que está ocurriendo. Los detalles técnicos de 
proyectos antiguos a veces se pierden para siempre o se recuperan sólo 
tras el trabajo detectivesco que se lleva a cabo tras una emergencia. Á me- 
nudo la información se ha registrado; lo que ocurre es que es imposible 
encontrarla. 

Si un experimento del CERN fuese un desarrollo estático, toda la in- 
formación podría escribirse en un gran libro. Pero el CERN está cam- 
biando constantemente a medida que surgen nuevas ideas, a medida que 
aparece nueva tecnología y a fin de solucionar nuevos problemas técni- 
cos. Cuando se requiere que haya un cambio, éste afecta normalmente 
sólo a una pequeña parte de la organización. Surge una razón local para 
cambiar una parte del experimento o detector. En este momento, hay que 
rebuscar para descubrir qué otras partes o personas se verán afectadas. 
Mantener al día un libro resulta poco práctico, y la estructura del libro 
tendría que ser revisada constantemente. 

La clase de información de la que hablamos responde, por ejemplo, a 
preguntas como: 


¿Dónde se usa este módulo? 

¿Quién escribió este código? ¿Dónde trabaja? 
¿Qué documentos existen acerca de este concepto? 
¿Qué laboratorios se incluyen en este proyecto? 
¿Qué sistemas dependen de este aparato? 

¿Qué documentos se relacionan con éste? 


Los problemas de pérdida de información pueden ser especialmente 
graves en el CERN, pero en este caso (como en algunos otros), el CERN 
es un modelo en miniatura de cómo será el resto del mundo dentro de 
unos cuantos años. El CERN se encuentra ahora con problemas a los que 
el resto del mundo tendrá pronto que enfrentarse. Dentro de diez años 
puede haber muchas soluciones comerciales a los problemas anteriores, 
pero hoy día necesitamos algo que nos permita continuar !. 


1 Ocurre lo mismo, por ejemplo, con los portales de correo electrónico, prepara- 
ción de documentos y sistemas de programación distribuidos heterogéneamente. 
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SISTEMAS DE INFORMACIÓN VINCULADA 


Al proporcionar un sistema para manipular ese tipo de información, sería 
deseable que un conjunto de' información pudiera desarrollarse, crecer y 
evolucionar con la organización y los proyectos que describe. Para que 
eso sea posible, 


el método de almacenamiento no debe trasladar sus propias restriccio- 
nes a la información. 


Por eso una “red” de notas con vínculos (como referencias) entre 
ellas es mucho más útil que un sistema jerárquico fijo. Cuando se describe 
un sistema complejo, mucha gente recurre a diagramas con círculos y fle- 
chas. Los círculos y las flechas le dejan a uno la posibilidad de describir 
las interrelaciones entre las cosas de un modo que las tablas, por ejemplo, 
no pueden hacer. El sistema que necesitamos es como un diagrama de cír- 
culos y flechas, donde los círculos y las flechas pueden ser cualquier cosa, 

Podemos llamar a los círculos nodos, y a las flechas vínculos. Supon- 
gamos que cada nodo es como una pequeña nota, resumen de artículo o 
comentario. No hablaré aquí de si tienen texto, gráficos o ambas cosas. 
Idealmente representa o describe una persona u objeto en particular. 
Ejemplos de nodos pueden ser: 


e Personas 

Módulos de software 

Grupos de personas 

Proyectos 

Conceptos 

e Documentos 

» Tipos de hardware 

* Objetos de hardware específicos 


Las flechas que vinculan el círculo A al círculo B pueden significar, por 
ejemplo, que A... 


* depende de B 
e es parte de B 
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e haceB 

e se refiere a B 

e usaB 

e esun ejemplo de B 


Estos círculos y flechas, nodos y vínculos?, tienen diferente significa- 
do en varias clases de diagramas convencionales: 


Diagrama Los nodos son Las flechas significan 
Árbol de familia Personas “Es pariente de” 
Diagrama dataflow Módulos de software “Pasa datos a” 
Dependencia Módulo “Depende de” 
Cuadro PERT Tareas “Debe hacerse antes” 
Cuadro de organización Personas “Informa a” 


El sistema debe permitir que se introduzca cualquier tipo de informa- 
ción, otra persona debe poder encontrar la información, a veces sin saber 
ni lo que está buscando. 

En la práctica, es útil que el sistema sea consciente de los tipos genéri- 
cos de vínculos entre los temas (las dependencias, por ejemplo) y los tipos 
de nodos (personas, cosas, documentos...) sin imponer ninguna limi- 
tación. 


El problema de la estructura en árbol 


Muchos sistemas están organizados jerárquicamente. El sistema de docu- 
mentación CERNDOC es un ejemplo de ello, como el sistema de archi- 
vos Unix, y el sistema VMS/HELP. Un árbol tiene la ventaja práctica de 
dar a cada nodo un nombre único. Sin embargo, no permite al sistema se- 
guir el modelo del mundo real. Por ejemplo, en un sistema HELP jerár- 


2 Los sistemas de información vinculada tienen entidades y relaciones. Hay, sin 
embargo, muchas diferencias entre un sistema así y un sistema de base de datos de 
“Relación de entidad”. Para empezar, la información almacenada en un sistema vincu- 
lado es en gran parte una explicación para el lector humano. En segundo lugar, los no- 
dos no tienen modelos estrictos que definan exactamente qué relaciones pueden tener. 
Nodos de tipo similar no tienen por qué estar todos almacenados en el mismo lugar. 
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quico como el VMS/HELP, a menudo conseguimos una hoja en ese árbol 
como 


HELP COMPILER SOURCE_FORMAT PRAGMAS .DEFAULTS 
para encontrar una referencia a otra hoja: “Por favor, véase 


HELP COMPILER COMMAND OPTIONS DEFAULTS PRAGMAS” 


y es necesario salir del sistema y volver a entrar en él. Lo que se necesitaba 
era un vínculo de un nodo a otro, porque en ese caso la información no se 
organizaba de manera natural en un árbol. 

Otro ejemplo de un sistema con estructura de árbol es el sistema de 
Noticias uucp (probar “rn” en Unix). Es un sistema jerárquico de discu- 
siones (“grupos de noticias”), que contienen cada uno artículos hechos 
por muchas personas. Es un método muy útil para aunar competencias, 
pero sufre de la inflexibilidad de la forma árbol. Normalmente, una dis- 
cusión en un grupo de noticias se desarrollará hacia un nuevo tema, mo- 
mento en el cual deberá estar en otra parte del árbol (véase figura 1). 


El problema de las palabras clave 


Las palabras clave son un método común para acceder a datos de los que 
no tenemos las coordenadas exactas. El problema habitual de las palabras 
clave, sin embargo, es que las personas nunca escogen las mismas pala- 
bras clave. Las palabras clave son sólo útiles entonces para la gente que ya 
conoce bien la aplicación. 

Los sistemas prácticos de palabras clave (como los de VAX/NOTES 
por ejemplo) requieren que se registren palabras clave. Esto ya es un paso 
en la dirección correcta. 

Un sistema vinculado lleva esto al siguiente paso lógico. Las palabras 
claves pueden ser nodos que significan un concepto. Un nodo de palabra 
clave no es pues diferente de cualquier otro nodo. Se pueden vincular do- 
cumentos, etc., a palabras clave. Se pueden luego encontrar palabras cla- 
ve encontrando cualquier nodo con el que estén relacionadas. De esta 
forma, documentos sobre temas similares se vinculan indirectamente, a 
través de sus conceptos clave. 
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FIGURA 1. Artículo en el esquema UUCP News 


From mcvax!uunet !pyrdc!pyrnj !rutgers!bellcore!geppetto!duncan 
Thu Mar... 

Article 93 of alt.hypertext: 

Path: cernvaximcvax!luunet ipyrdc!pyrnj!rutgers!bellcore!geppetto! 
duncan ) 

>From: duncantgeppetto.ctt.bellcore.com (Scott Duncan) 
Newsgroups: alt.hypertext 

Subject: Re: Threat to free information networks 
Message-1D: <14646€bel1lcore.bellcore.com> 

Date: 10 Mar 89 21:00:44 GMT 

References: <1784.2416BB4741isishq. FIDONET.ORG> <34374uhccux. 
uhcc... 

Sender: newstbellcore.bellcore.com 

Reply-To: duncantctt.bellcore.com (Scott Duncan) 
Organization: Computer Technology Transfer, Bellcore 

Lines: 18 


Doug Thompson ha escrito un artículo muy serio en mi opinión 
sobre la censura; mi aceptación o rechazo de sus comentarios, 


sin embargo, no está especialmente relacionado con este envío. 


En respuesta Greg Lee ha objetado de modo algo conciso. 


i pregunta (y la razón de este envío) es preguntar dónde 
podríamos discutir más este tema. De algún modo, alt.hypertext 
no me parece el lugar adecuado. 
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Quizá a la gente le parezca bien trasladarse a alt.individualism 
o incluso a uno de los grupos soc. No me preocupa mucho el tema 
específico de la censura de rec.humor.funny, sino en los puntos 


de vista presentes en el artículo de Greg. 


Hablo sólo por mí, claro. Soy... 
Scott P. Duncan (duncanectt.bellcore.com OR ...!bellcore!ctt! 
duncan) 


(Bellcore, 444 Hoes Lane RRC 14-210, Piscataway, 


NJ...) 
(201-699-3910 (w) 201-463-3683 (h)) 


El campo de Tema permite hacer notas sobre el mismo tema que puede vincularse 
con un “grupo de noticias”. El nombre del grupo de noticias (alt. hypertext) es un 
nombre jerárquico. Esta nota en particular expresa un problema con la estricta es- 
tructura de árbol del esquema: esta discusión está relacionada con varias áreas. Nóte- 


y 


se que los campos “References”, “From? y “Subject” pueden usárse para generar 


vínculos. 
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Una búsqueda con palabra clave se convierte entonces en una bús- 
queda que empieza en un pequeño número de nodos con nombre, y en 
encontrar nodos que estén cercanos a todos ellos. 

Por estas razones hice al principio un pequeño sistema de informa- 
ción vinculada, sin darme cuenta de que ya se había acuñado un término 
para esa idea: “hipertexto”. 


UNA SOLUCIÓN: EL HIPERTEXTO 
Experiencia personal con el hipertexto 


En 1980 escribí un programa para localizar software que utilizaba en el 
sistema de control PS. Llamado Enquire, permitía almacenar partículas 
de información y vincular objetos relacionados de cualquier forma posi- 
ble. Para encontrar información, se avanzaba por medio de los vínculos 
de una hoja a otra, como en el viejo juego “aventura” de ordenador. Usé 
esto para mi propio registro de personas y módulos. Era semejante a la 
aplicación Hypercard hecha recientemente por Apple para los Macintosh. 
Pero una diferencia era que Enquire, aunque carecía de gráficos, funcio- 
naba en un sistema multiusuario y permitía que mucha gente accediese a 
los mismos datos. 


FIGURA 2, Pantalla en un sistema Enquire 


Documentación del proyecto RPC (concepto) 


La mayoría de la documentación está disponible en VMS, y 
los dos manuales principales están almacenados en el sistema 
CERNDOC. 


) incluye: La conferencia VAX/NOTES VXCERN: :RPC 
) incluye: test y ejemplo 
) incluye: LISTAS DE VIRUS RPC 
) incluye: Sistema RPC : Guía de mejora 
Información para mantenimiento, presentación, etc. 
5) incluye: Estrategia de desarrollo sugerido para aplicacio- 
nes RPC 
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6) incluye: “Notas sobre RPC*, Borrador 1, 20 feb 86 

7) incluye: “Notas sobre desarrollo RPC propuesto” 18 Feb 
86 : 

8) incluye: Manual del Usuario RPC 
Cómo construir y hacer funcionar un sistema distribui- 
do . ; 

9) incluye: Borrador de especificaciones y notas de pues- 
ta en práctica 

10) incluye: La propiedad RPC HELP 

11) describe: EL PROYECTO DE LLAMADA DE PROCEDIMIENTO RE- 
MOTO en DD/OC 


Ayuda Pantalla Selecccionar Atrás Salir Marca Ir a_marca Vínculo Añadir Editar 


Este ejemplo es básicamente una lista, así que la lista de vínculos es 
más importante que el propio texto del nodo. Nótese que cada vínculo 
tiene un tipo (“incluye”, por ejemplo) y puede llevar también un comen- 
tario asociado. (La línea inferior es una barra de menú.) 

Poco después de mi vuelta al CERN en el departamento DD, descu- 
brí que el entorno era semejante al de PS, y echaba de menos el Enquire. 
Por tanto hice una versión para el VMS y lo usé para localizar proyectos, 
personas, grupos, experimentos, módulos de software y aparatos de hard- 
ware con los que había trabajado. Yo lo había encontrado muy útil perso- 
nalmente. No me costó ningún esfuerzo hacerlo utilizable por la gente en 
general, pero descubrí que muy pocas personas lo habían utilizado con 
éxito para navegar por los proyectos y descubrir toda clase de cosas que 
les pudieran interesar, 


Puntos calientes 


Mientras tanto, varios programas habían estado explorando esas ideas, 
tanto comercial como académicamente. La mayoría de ellos usaban 
“puntos calientes” en documentos, como iconos, o frases subrayadas, 
como zonas a destacar. Tocar un punto caliente con el ratón hace apare- 
cer la información relevante o expande el texto en la pantalla para incluir- 
lo. Imaginemos, pues, las referencias en este documento, todas asociadas 


208 Apéndice 


con la dirección de red de la cosa a la que se refieren, de modo que mien- 
tras se lee ese documento se puede ir hasta ella con un clic del ratón. 

El “hipertexto” es un término acuñado en los cincuenta por Ted Nel- 
son [...], que se ha vuelto famoso por esos sistemas, aunque se usa para 
abarcar dos ideas diferentes. Una idea (que tiene que ver con este proble- 
ma) es el concepto siguiente: 


“Hipertexto”: información legible por los seres humanos vinculada 


entre sí de manera no obligatoria, 


La otra idea, que es independiente y en gran parte cuestión de tec- 
nología y tiempo, es la de documentos multimedia que incluyen gráficos, 
audio y vídeo. No hablaré más de este último aspecto aquí, aunque usaré 
la palabra “Hipermedios” para indicar algo que no se limita al texto. 

Ha sido difícil evaluar el efecto de un gran sistema de hipermedios en 
una organización, a menudo porque esos sistemas nunca se han usado se- 
riamente a gran escala. Por esta razón, necesitamos que grandes cantida- 
des de información existente sean accesibles usando cualquier nuevo sis- 
tema de gestión de información. 


REQUISITOS DEL CERN 

Para que un sistema sea práctico en el entorno CERN, es necesario que se 
cumplan cierto número de requisitos prácticos. 

Acceso a larga distancia por las redes 


El CERN es extenso, y el acceso desde aparatos lejanos es esencial, 


Heterogeneidad 


Es necesario el acceso a los mismos datos desde diferentes tipos de siste- 


ma (VM/CMS, Macintosh, VAX/VMS, Unix). 
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Descentralización 


Los sistemas de información empiezan por ser pequeños y crecen. Tam- 
bién empiezan por estar aislados y luego se fusionan. Un nuevo sistema 
debe permitir a los sistemas existentes que se vinculen entre sí sin necesi- 
dad de ningún control o coordinación central. 


Acceso a datos existentes 


Si proporcionamos acceso a las bases de datos existentes como si estu- 
vieran en forma de hipertexto, el sistema despegará más rápidamente. 
De esto se hablará más adelante. 


Vínculos privados 


Uno debe poder añadir sus propios vínculos privados a la información 
pública y a partir de ella. También se deben poder anotar vínculos, así 
como nodos, de manera privada. 


Campanas y silbatos 


El almacenamiento de texto ASCIT y su aparición en pantallas de 24 x 80 
es a corto plazo suficiente y esencial, Añadir gráficos será una opción ex- 
tra con mucha menos penetración de momento. 


Análisis de datos 


Una posibilidad intrigante, dada una gran base de datos de hipertexto 
con vínculos tecleados, es que permite cierto grado de análisis automáti- 
co. Es posible buscar, por ejemplo, anomalías tales como software no do- 
cumentado o departamentos que no contengan personal. Es posible ge- 
nerar listas de personas o aparatos para otros propósitos, como listas de 
correo de personas a las que haya que informar sobre cambios. 
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También es posible contemplar la topología de una organización o de 
un proyecto, y sacar conclusiones acerca de cómo deberían gestionarse y 
cómo podrían evolucionar. Esto es especialmente útil cuando la base de 
datos se vuelve demasiado grande y los grupos y proyectos, por ejemplo, 
llegan a estar tan interrelacionados que es difícil distinguir los árboles del 
bosque. ES A 

En un lugar complejo como el CERN, no siempre está muy claro el 
modo en que las personas se dividen en grupos. Imaginemos que hemos 
hecho un gran modelo tridimensional, con personas representadas por 
pequeñas esferas y cuerdas entre las personas que tengan algo en común 
en el trabajo. 

Ahora imaginemos que agarramos la estructura y la sacudimos, hasta 
que observemos que el embrollo tiene cierto sentido: quizá veamos gru- 
pos muy estrechamente entrelazados en algunas zonas, y en otras, zonas 
débiles de comunicación pobladas sólo por unas pocas personas. Quizá 
un sistema de información vinculada nos permita ver la estructura real de 
la organización en la que trabajamos. 


Vínculos vivos 


Los datos a los que se refiere un vínculo (o punto caliente) pueden ser 
muy estáticos, o pueden ser temporales. En muchos casos, la información 
que hay en el CERN a propósito del estado de los sistemas está cambian- 
do constantemente. El hipertexto permite que los documentos se vincu- 
len a datos “vivos”, de modo que cada vez que se sigue el vínculo, la infor- 
mación se recupera. Si uno sacrifica la movilidad, sería posible que al 
seguir un vínculo apareciese una aplicación especial, de modo que los 
programas de diagnóstico, por ejemplo, pudieran ser vinculados directa- 
mente con la guía de mantenimiento. 


Falta de requisitos 


Las conversaciones sobre hipertexto han llegado a veces a la cuestión de 
la concesión del copyright y la seguridad de los datos. Esto tiene en el 
CERN una importancia secundaria, pues aquí el intercambio de informa- 
ción es aún más importante que la discreción. La autorización y los siste- 
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mas de contabilidad para el hipertexto podrían seguramente ser diseña- 
dos de manera muy sofisticada, pero aquí no se habla de ello. 

En casos en los que haya que referirse a datos que están protegidos, 
deberían bastar los sistemas de protección de archivos ya existentes, 


APLICACIONES ESPECÍFICAS 


A continuación hay tres ejemplos de lugares específicos en los que el sis- 
tema propuesto debería ser útil inmediatamente. Hay muchos otros. 


Documentación de desarrollo de un proyecto 


El proyecto de Llamada de procedimiento remoto tiene una descripción 
esquemática que usa el Enquire. Aunque sea limitada, es muy útil para re- 
gistrar quién hizo qué, dónde están, qué documentos existen, etc. Tam- 
bién se puede seguir la pista a los usuarios y puede añadirse muy fácilmen- 
te cualquier fragmento más de información que llega y que no tiene un 
lugar específico en que ponerse. Los vínculos cruzados que vayan a otros 
proyectos y a bases de datos que contengan información sobre personas y 
documentos serían muy útiles y ahorrarían duplicados de información. 


Recuperación de documentos 


El sistema CERNDOC proporciona la mecánica necesaria para almace- 
nar e imprimir documentos. Un sistema vinculado permitiría navegar por 
conceptos, documentos, sistemas y autores, permitiendo además almace- 
nar referencias entre documentos. (Una vez que un documento se hubie- 
ra encontrado, la maquinaria existente podría imprimirlo o mostrarlo.) 


El “Inventario de habilidades personales” 


Las habilidades y experiencia personales son esa clase de cosas que nece- 
sitan de la flexibilidad del hipertexto. La gente puede vincularse a proyec- 
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tos en los que han trabajado, que pueden a su vez vincularse a aparatos 
determinados, lenguajes de programación, etc. 


LOS HIPERMEDIOS MÁS NOVEDOSOS 


Se está trabajando cada vez más en la investigación de hipermedios en uni- 
versidades y laboratorios de investigación comercial. De estas investigacio- 
nes han salido algunos sistemas comerciales. Ha habido dos conferencias, 
Hypertext '87 y '88, y en Washington D.C., el Instituto Nacional de Están- 
dares y Tecnología (NST) ha albergado un taller de trabajo sobre la nor- 
malización del hipertexto, del que se hará un seguimiento durante 1990, 

El número especial de Communications of tbe ACM sobre hipertexto 
contiene muchas referencias a artículos sobre hipertexto. Se proporciona * 
una bibliografía [NIST9O] y existe un grupo de noticias uucp alt.hyper- 
text. De todos modos yo no doy aquí la lista, 


Técnicas de navegación 


Gran parte de la investigación académica se refiere al lado humano de la” 
navegación por un medio complejo de información. Los problemas trata- 
dos son aquellos que hacen fácil la navegación y evitan una sensación de 
estar “perdidos en el hiperespacio”. Aunque los resultados de la investi- 
gación son interesantes, muchos usuarios en el CERN accederán al siste- 
ma usando terminales primitivos, y estilos de ventanas tan avanzados no 
nos resultan fundamentales. 


¿Interconexión o publicación? 


La mayoría de los sistemas que están disponibles hoy día usan una sola 
base de datos. A ésta acceden muchos usuarios utilizando un sistema de 
archivos distribuidos. Hay pocos productos que recojan literalmente la 
idea de Ted Nelson de un amplio “docuverse”, permitiendo crear víncu- 
los entre nodos en diferentes bases de datos. Para hacer esto sería necesa- 
ria cierta normalización. Sin embargo, en el taller de normalización, se su- 
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brayó sobre todo la normalización del formato para los medios intercam- 
biables, no para las redes. Esto lo produce el fuerte impulso hacia la pu- 
blicación de información de hipermedios, por ejemplo en disco óptico. 
Parece haber un consenso general acerca del modelo abstracto de datos 
que debería usar un sistema de hipertexto. 

Se han establecido muchos sistemas con poco o ningún interés por la 
movilidad, por desgracia. Otros, aunque publicados, son software priva- 
do que no se distribuirá. Sin embargo, hay varios proyectos interesantes y 
están apareciendo cada vez más. El “Compound Document Architecture” 
(CDA) de Digital, por ejemplo, es un modelo de datos que puede ser ex- 
tensible a un modelo de hipermedios, y hay rumores de que por ahí es por 
donde puede ir Digital. 


Incentivos y CALS 


El Departamento americano de Defensa ha dado un gran incentivo a la 
investigación de hipermedios especificando documentación de hiperme- 
dios para su futura adquisición. Esto significa que todos los manuales de 
piezas de equipo de defensa deben suministrarse en forma de hiperme- 
dios. Las siglas CALS significan “Adquisición asistida por ordenador y 
apoyo logístico”. 

La industria editorial también ofrece un gran apoyo, y también los li- 
breros, cuya misión consiste en organizar la información. 


¿Qué aspecto tendrá el sistema? 


Veamos qué componentes debe poseer un sistema de hipertexto en el 
CERN. 

La única manera de que se pueda incorporar la flexibilidad suficiente 
para ello es separar el almacenamiento de información del software de 
muestra de información, con un interface bien definido entre ellos. Dado 
que es necesario acceder a una red, es lógico dejar que este interface coin- 
cida con la división física entre el usuario y el aparato remoto con la base 
de datos?. 


3 Un cliente/servidor dividido a este nivel también hace que el multiacceso sea más 
fácil, ya que un único proceso de servidor puede servir a muchos clientes, evitando los 
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Esta división también es importante a fin de permitir la heterogenei- 
dad que es necesaria en el CERN (y debería ser una ventaja para el mun- 
do en general, 


FIGURA 3. Modelo de cliente/servidor para sistema de hipertexto distribuido - 


La información de un o 
servidor se refiere a la 


“2 información de otro 


Programa “navegador” 
cliente que funciona en 
muchas plataformas 


y 
Servidor 


de hipertexto : : - 


Por tanto, definir este interface es una fase importante en el diseño del 
sistema. Después, se puede proceder paralelamente a desarrollar diversas 
formas de programa de display y de servidor de bases de datos. Esto se 
habrá hecho bien si se pueden definir muchas fuentes diferentes de infor- 
mación pasadas, presentes y futuras, y si muchos programas interface hu- 
manos pueden escribirse a lo largo de los años para aprovechar las nuevas 
tecnologías y estándares. 


problemas de acceso simultáneo a una base de datos por parte de muchos usuarios di- 
ferentes. 


Gestión de información: una propuesta 215 


ACCESO A DATOS EXISTENTES 


El sistema debe conseguir una utilidad crítica enseguida. Los sistemas exis- 
tentes de hipertexto han tenido que justificarse a sí mismos sólo en lo que 
se refiere a nuevos datos. Si, sin embargo, hubiera una base de datos exis- 
tente de personal, por ejemplo, a la que pudieran vincularse nuevos da- 
tos, el valor de cada nuevo dato sería mayor, 

Lo que es necesario es un nuevo programa portal que modelará una 
estructura existente sobre el modelo de hipertexto y permitirá acceso li- 
mitado (quizá sólo para ser leído) a él. Esto adquiere la forma de un servi- 
dor de hipertexto escrito para proporcionar información en una forma 
que combine con el interface estándar. No nos imaginamos que el servi- 
dor genere realmente una base de datos de hipertexto a partir de una ya 
existente; más bien generaría una visión de hipertexto de una base de da- 
tos existente. 


FIGURA 4. Un portal de hipertexto permite que un navegador de hipertexto 
vea los datos existentes 


navegador genérico 


simulador de servidor de 

hipertexto que hace que 

bases de datos existentes 
servidor de parezcan hipertexto al 


hipertexto navegador 
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Algunos ejemplos de los sistemas que pueden conectarse así son 


Noticias uucp 

Es un sistema de conferencias electrónico de Unix. Un servidor de noti- 
cias uucp establece vínculos entre notas sobre el mismo tema, además de 
mostrar la estructura de las conferencias. 


VAX/Notas 

Es un sistema de conferencias electrónico de Digital. Tiene un gran segui- 
miento en FermiLab, pero mucho menos en el CERN. La topología de 
una conferencia es bastante restrictiva, 


CERNDOC 

Es un sistema de registro y distribución de documentos que funciona en 
el aparato VM del CERN. Además de documentos, categorías y proyec- 
tos, las palabras clave y los autores se prestan a ser representados como 
nodos de hipertexto. 


Sistemas de archivo 
Esto permitiría que cualquier archivo se pudiera vincular a partir de otros 
documentos de hipertexto. 


Guía telefónica 
Incluso esto puede contemplarse como hipertexto, con vínculos entre per- 
sonas y secciones, secciones y grupos, personas y pisos de edificios, etc. 


El manual unix 

Es un gran compendio de texto legible por ordenador, organizado actual- 
mente de un modo plano, pero que también contiene información de vín- 
culos en formato estándar (“Ver también...”). 


Bases de datos 

Una herramienta genérica podría quizá hacerse de modo que permitiera 
que cualquier base de datos que usa un DBMS comercial pueda ser mos- 
trada como hipertexto. 


En algunos casos, escribir estos servidores querrá decir descifrar u. 
obtener detalles de los protocolos existentes y/o formatos de archivos. 
Puede no ser práctico proporcionar la funcionalidad completa del siste- 
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ma original a través del hipertexto. En general, será más importante per- 
mitir acceso de lectura al público: es posible que haya un número limita- 
do de personas que proporcionen la información, y que estén satisfechos 
con la utilización de los medios existentes. 

Á veces es posible mejorar un sistema de almacenamiento existente 
codificando en él información de hipertexto, si se sabe que un servidor va 
a generar una representación de hipertexto. En artículos de “noticias”, 
por ejemplo, se puede usar (en el texto) un formato estándar para hacer 
una referencia a otro artículo. Esto lo recogerá el portal de hipertexto y lo 
usará para generar un vínculo a esa nota. Este tipo de mejora permitirá 
una mejor integración entre sistemas nuevos y viejos. 

Siempre habrá un gran número de sistemas de gestión de informa- 
ción; conseguiremos que nos sean aún más útiles si somos capaces de cru- 
zar la información. Sin embargo, saldremos perdiendo si tratamos de 
constreñirlos, pues excluiremos sistemas y obstaculizaremos la evolución 
del hipertexto en general. 


CONCLUSIÓN 


Debemos trabajar para conseguir un sistema universal de información 
vinculada, en que la generalidad y la movilidad sean más importantes que 
las bonitas técnicas de gráficos y los complejos accesorios extra. 

El objetivo sería permitir que se encontrase un lugar para cada infor- 
mación o referencia que se considerase importante, y una manera de en- 
contrarlas más tarde. El resultado debería tener un uso lo suficientemente 
atractivo como para que la información contenida creciera más allá de un 
umbral crítico, de modo que la utilidad del esquema empujase a usarlo 
cada vez más. 

El paso de este umbral se aceleraría permitiendo que grandes bases 
de datos existentes se pudiesen vincular entre sí y con otras nuevas. 


Un proyecto práctico 


Aquí sugiero los pasos prácticos que tomar para encontrar una solución 
real en el CERN. Tras una discusión preliminar de los requisitos nombra- 
dos arriba, es necesario obviamente un estudio de lo que está disponible 
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en la industria. En este punto, estaremos buscando sistemas que sean a 
prueba de futuro: 


e Portátiles, o sostenidos por muchas plataformas 
e Extensibles a nuevos formatos de datos 


Podemos descubrir que con muy poca adaptación, se pueden combi- 
nar elementos del sistema que necesitemos, como por ejemplo, un nave- 
gador de una fuente con una base de datos de otra. 

Imagino que dos personas durante 6 a 12 meses serían suficientes 
para esta fase del proyecto. 

Una segunda fase llevaría sin duda consigo la necesidad de más pro- 
gramación a fin de establecer un sistema real en el CERN, en muchos 
aparatos. Una parte importante de esto, de la que se habla más abajo, es la 
integración de un sistema de hipertexto con datos existentes, para pro- 
porcionar un sistema universal, y conseguir una utilidad auténtica desde 
el principio. 

(¡...Y, en efecto, esto supondría un excelente proyecto con el que en- 
sayar nuestras nuevas técnicas orientadas a la programación!) 


TBL Marzo 1989, Mayo 1990 
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GLOSARIO 


Para más información y referencias sobre este libro, por favor véase 
bttp://wrww.w3.0rg/People/Berners-Lee/Weaving. 


accesibilidad: el arte de asegurarse de que las instalaciones como, por 
ejemplo, el acceso al Web, hasta donde sea posible, están a la disposi- 
ción dela gente, sean o no personas impedidas, física o psíquicamente. 

ACSS (Audio Cascading Style Sheets) [Hojas de Estilo Audio en Cas- 
cada]: un lenguaje que dice a un ordenador cómo leer en voz alta 
una página web. Esto forma ahora parte del CSS2. 

Amaya: un navegador/editor web de fuente abierta, de W3C y amigos, 
usado para impulsar ideas innovadoras en diseño de clientes web. 

Apache: un servidor web de fuente abierta hecho originalmente to- 
mando todos los “parches” (posiciones) del servidor web del 
NGSA y haciendo con ellos un nuevo servidor. 

aparatos móviles: buscapersonas, teléfonos, ordenadores manuales, 
etc. Todos son potencialmente aparatos de Internet y clientes web. 

CERN: el Laboratorio Europeo de Física de Partículas, que se en- 
cuentra en la frontera franco-suiza, cerca de Ginebra, Suiza. 

Click-stream: la información que nos dice qué partes del Web ha visi- 
tado un usuario. 

cliente: cualquier programa que use el servicio de otro programa. En 
el Web, un cliente web es un programa, como por ejemplo un na- 
vegador, un editor o robot buscador, que lee o escribe informa- 
ción en el Web. 

control de acceso: la capacidad para controlar selectivamente quién 
puede acceder a una información o manipularla en un servidor 
web, por ejemplo. 

CSS: (Cascading Style Sheets) [Hojas de Estilo en Cascada]: una reco- 
mendación W3C,; un lenguaje para escribir hojas de estilo. Ver 
también hoja de estilo. 
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Cyc: un proyecto de representación de conocimientos en el que un ár- 
bol de definición intenta expresar hechos del mundo real de un 
modo legible por una máquina. (Actualmente es una marca regis- 
trada de Cycorp Inc.) 

DOM (Document Object Model) [Modelo de Objeto Documento]: 
dentro de un ordenador, la información suele estar organizada 
como un conjunto de “objetos”. Cuando se transmite, se envía 
como “documento”. El DOM es una especificación W3C que 
proporciona un camino común a los programas para acceder a un 
documento como un conjunto de objetos. 

DTD: en el mundo SGML, un DTD es un metadocumento que con- 
tiene información acerca de cómo puede usarse un conjunto dado 
de etiquetas SGML. En el mundo XML, este papel lo asumirá un 
esquema. Á veces es, aunque es discutible, la “definición de docu- 
mento tipo”. Ver también esquema. 

Dublin Core: un conjunto de propiedades básicas de metadatos 
(como un título, etc.) para clasificar recursos web. 

EBT (Electronic Book Tecnology) [Tecnología de Libro Electrónico]: 
una empresa fundada por Andries Van Dam y otros para desarro- 
llar sistemas de hipertexto. 

EDI (Electronic Data Interchange) [Intercambio Electrónico de Da- 
tos]: un estándar anterior al Web para el intercambio electrónico 
de documentos comerciales. 

Enquire: un programa de 1980 que toma el título del libro victoriano 
Enquire Within About Everytbing. 

entendimiento parcial: la capacidad de entender parte del contenido 
de un documento que usa múltiples vocabularios, parte de los 
cuales se entiende. 

espacio de información: el concepto abstracto de todo lo que es acce- 
sible usando redes: el Web. 

esquema: un documento que describe un vocabulario XML o RDE 

filtrado: el establecimiento de criterios para seleccionar un subcon- 
junto de datos de entre una gran cantidad de los mismos. El filtra- 
do de datos es esencial para todos en la vida diaria. El filtrado por 
parte de los padres de lo que llega a los niños puede ser prudente. 
El filtrado de otros —ISP o gobiernos— es malo, y se llama censura. 

firma digital: un número muy grande creado de tal modo que puede 
demostrarse que sólo ha podido hacerlo una persona que posea 
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una clave secreta y sólo procesando un documento con un conte- 
nido determinado. Puede usarse para los mismos fines que la fir- 
ma escrita de una persona en un documento físico. Algo que pue- 
de hacerse con la criptografía de clave pública. Los trabajos del 
W/3C dirigen la firma digital de los documentos XML. 

fuente abierta: software cuyo código fuente se distribuye gratuita- 
mente y es modificable por cualquiera. El código muestra de W3C 
es software de fuente abierta. Una marca registrada de opensour- 
Ce.org. 

GIF (Graphic Interchange Format) [Formato de Intercambio Gráfi- 
co]: un formato para imágenes transmitidas pixel a pixel por In- 
ternet. Creada por CompuServe, la especificación GIF se hizo de 
dominio público, pero Unisys consideró que tenía una patente de 
la tecnología de compresión utilizada. Esto estimuló el desarrollo 
del PNG. 

GILC (Global Internet Liberty Campaign) [Campaña Global de Li- 
bertad en Internet]: un grupo que fue muy activo en el apoyo de 
los derechos individuales en Internet (aunque a veces tendía a no 
saber separar el polvo de la paja). 

gráficos: imágenes en dos o tres dimensiones, generalmente dibujos o 
fotografías. Ver también GE, PNG, SVG y VMRL. 

hipertexto: escritura no secuencial; el término de Ted Nelson para 
describir un medio que incluye vínculos. Actualmente incluye 
otros medios, aparte de textos, y es a veces llamado hipermedio. 

hipertexto virtual: el hipertexto que un programa genera a partir de 
su URI, en vez de recurriendo a un archivo guardado. 

hoja de estilo: un documento que explica a un programa de ordena- 
dor (como un navegador, por ejemplo) cómo traducir el markup 
del documento en una presentación particular (fuentes, colores, 
espaciado, etc.) en la pantalla o en una hoja impresa. Ver también 
CSS, XSL, separación de la forma y el contenido. 

HTML (Hypertext Markup Language) [Lenguaje Markup de Hiper- 
texto]: un lenguaje de ordenador para representar el contenido de 
una página de hipertexto; el lenguaje en el que están escritas la 
mayoría de páginas web. 

HTTP (Hipertext Transfer Protocol) [Protocolo de Transferencia de 
Hipertexto]: un protocolo de ordenador para transferir informa- 
ción por Internet de modo tal que pueda cumplir las demandas de 
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un sistema de hipertexto global. Parte del diseño original del Web, 
continuado como actividad W3C, que es ahora el borrador de un 
estándar HTTP 1.1 IETE 

INRIA (Institut National de Recherche en Informatique et Automati- 
que) [Instituto Nacional de Investigación Informática y Automáti- 
cal: el laboratorio nacional francés de investigación de ciencias in- 
formáticas y control. Colaborador de W3C y promotores de 
Amaya. 

Internet: una red de redes global por medio de la cual se comunican 
los ordenadores enviando información en paquetes. Cada red 
consiste en ordenadores conectados por cables o por enlaces sin 
hilos. 

Intranet: una parte de Internet o parte del Web usada internamente 
dentro de una compañía u organización. 

IP (Internal Protocol) [Protocolo Interno]: el protocolo que gobierna 
el modo en que los ordenadores envían paquetes por Internet. Di- 
señado por Vint Cerf y Bob Kahn. (TP también puede querer decir 
propiedad intelectual, ver PR). 

IPR (Intelectual Property Rights) [Derechos de Propiedad Intelec- 
tual]: las condiciones según las cuales la información creada por 
una parte puede ser utilizada por otra parte. 

ISO (International Standards Organization) [Organización de Están- 
dares Internacional]: un grupo internacional de organismos de es- 
tándares nacionales. 

ISP (Internet Service Provider) [Servicio de Proveedor de Internet]: 
la parte que proporciona conexión a Internet. Algunos usuarios 
tienen un cable u otro tipo de enlace sin hilos con su ISP. En otros 
casos, el ordenador puede marcar el número de teléfono de un 
ISP y mandar y recibir paquetes de Internet por la línea telefónica; 
el ISP expide los paquetes por Internet. 

Java: un lenguaje de programación desarrollado (originalmente como 
“Oak”) por James Gosling, de Sun Microsystems. Diseñado para 
permitir capacidad de transporte y uso en aparatos pequeños, Java 
despegó como lenguaje para aplicaciones pequeñas (“applets”) 
que funcionan dentro de un navegador web. 

Jigsaw: servidor web de fuente abierta de gran modularidad, escrito 
en Java. De W3C y amigos. 

JPEG [Joint Photographic Experts Group) [Grupo de Expertos Fo- 
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tográficos Unidos]: este grupo definió un formato para codificar 
fotografías que usa menos bytes que los sistemas pixel a pixel de 
GIF y PNG, sin que haya una gran degradación de calidad visible. 
El formato (JFIF) suele llamarse JPG. 

LGS (Laboratory of Computer Science) [Laboratorio de Ciencias In- 
formáticas]: un laboratorio que se encuentra en el Instituto de 
Tecnología de Massachusetts. Colaborador de W3C. 

LEAD (Live Early Adoption and Demonstration) [Adopción y Demos- 
tración Temprana]: una política de W3C que consiste en probar 
todos nuestros productos para descubrir cómo pueden mejorarse. 

libwww: la biblioteca (colección) de módulos relacionados con pro- 
gramas WWW que está disponible para su libre uso por parte de 
cualquiera desde los primeros tiempos del Web. 

meta-: un prefijo que indica que algo se aplica a sí mismo; por ejem- 
plo, una metareunión es una reunión acerca de reuniones. 

metadatos: datos acerca de datos del Web, incluyendo, pero no sólo, 
la autoría, la clasificación, la aprobación, la política, la distribu- 
ción, los términos, los IPR, etc. Un uso significativo del Web Se- 
mántico. 

micropagos: una tecnología que permite a alguien pagar el acceso a un 
sitio web en cantidades muy pequeñas mientras navega. 

mínima molestia, principio de: la idea de que la ingeniería u otros di- 
seños deben definir sólo lo que tienen que hacer, dejando otros as- 
pectos del sistema y otros sistemas tan líbres como sea posible. 

MIT (Massachusetts Institute of Technology) [Instituto de Tecnología 
de Massachusetts]: Ver LCS. Colaborador de W3C. 

modo-línea: en tiempos lejanos, la gente no veía los programas de or- 
denadores por ventanas. Tecleaban comandos en un terminal y el 
ordenador contestaba con texto, que se desplegaba en la pantalla 
(o se imprimía en un rollo de papel) con los comandos intercala- 
dos, igual que si la persona estuviera en un chat con el programa 
de ordenador. Si han visto una “ventana DOS”, tendrán una idea 
de cómo la gente se comunicaba con los ordenadores en aquellos 
días, antes de aprender cómo arrastrar y soltar. El modo-línea si- 
gue siendo una manera muy respetable de comunicarse con un or- 
denador. 

Mosaic: un navegador web desarrollado por Marc Andreessen, Eric 
Bina y sus colegas en el NCSA. 
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navegador: un cliente web que permite a un ser humano leer informa- 
ción en el Web. 

navegador modo-línea: un cliente web que se ha comunicado con el 
usuario en modo-línea y puede hacer funcionar todo tipo de órde- 
nadores que no tengan ventanas o ratones. 

NCSA (National Center for Supercomputing Applications) [Centro 
Nacional de Aplicaciones de Superinformática]: un centro de la 
Universidad de Illinois, en Urbana-Champaign, cuyo grupo de de- 
sarrollo de software creó el Mosaic. 

Nelson, Ted: el que acuñó el término hipertexto; gurú y visionario. 

Net: abreviatura de Internet. 

NeXT: nombre de la compañía fundada por Steve Jobs, y del lena 
dor que fabricaba, que integraba muchas novedades como el nú- 
cleo Mach, Unix, NeXTStep, Objective-C, constructores de apli- 
caciones de arrastrar y soltar, discos Ópticos y procesadores de 
señal digital. La plataforma de desarrollo que usé para el primer 
cliente web. 

NNTP (Network News Transfer Protocol) [Protocolo de Transferen- 
cia de Noticias por Red]: un protocolo que define cómo van pa- 
sando los nuevos artículos por los ordenadores. Cada ordenador 
pasa un artículo a cualquiera de sus vecinos que aún no lo tengan. 

nodo: cosa unida por vínculos. En el Web, un nodo es una página 
web, cualquier recurso con un URI. 

nombre de dominio: un nombre (como w3.org) de un servicio, sitio 
web u ordenador, y así sucesivamente en un sistema delegado de 
autoridad jerarquizada, el Sistema de Nombre de Dominio. 

paquete: una unidad en la que la información se divide para que sea 
transmitida por Internet. 

PGP (Pretty Good Privacy) [Privacidad Bastante Buena]: un sistema 
de seguridad para e-mails que usa la criptografía de clave pública 
y tiene la filosofía de que los individuos puedan escoger de quién 
fiarse con qué propósito; la “red de confianza”. 

PICS (Platform for Internet Content Selection) [Plataforma para la 
Selección del Contenido de Internet]: tecnología de W3C que per- 
mite a los padres seleccionar contenidos para sus hijos en base a 
un criterio abierto, opuesto a la censura del gobierno. Ver filtrado. 

PKC (Public Key Criptography) [Criptografía de Clave Pública]: un 
sistema matemático en el que se basa un sistema de seguridad 
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donde no es necesario el intercambio de claves secretas; en lugar 
de ello, la persona tiene una clave “privada” que sólo ella sabe y 
una clave “pública” que conoce todo el mundo. 

PKI (Public Key Infrastructure) [Infraestructura de Clave Pública]: 
una jerarquía de “autoridades de certificación” que permite a los 
individuos y organizaciones identificarse unos a otros con el pro- 
pósito (principalmente) de hacer negocios electrónicamente. 

PNG (Portable Network Graphics) [Gráficos de Red Portátill: un 
formato que codifica una imagen pixel a pixel, y la manda por el 
Net. Una recomendación del W3C, que sustituye al GIE 

protocolo: un lenguaje y un conjunto de reglas que permite a los orde- 
nadores interactuar de un modo bien definido. Ejemplos son el 
FTP, el HTTP y el NNTP. 

RDF (Resource Description Framework) [Estructura de Descripción 
de Recursos]: una estructura para construir lenguajes lógicos que 
puedan funcionar juntos en el Web Semántico. Una manera de 
usar el XML para datos en lugar de sólo para documentos. 

registro MARC: un patrón de tarjetas legibles por máquinas de catá- 
logos de bibliotecas. - 

RPC (Remote Procedure Call) [Llamada de Procedimiento Remoto]: 
cuando una parte del programa llama a otra parte para hacer al- 
gún trabajo, la acción se llama llamada de procedimiento. El RPC 
es un conjunto de herramientas que nos permiten escribir un pro- 
grama cuyas diferentes partes están en diferentes ordenadores, sin 
tener que preocuparse por el modo en que tiene lugar la comuni- 
cación. Una técnica genérica, no un producto específico. 

RSA: un sistema de encriptamiento de clave pública inventado por 
Ron Rivest, Adi Shamir y Leonard Adleman. Los algoritmos RSA 
han sido patentados, y sus inventores han adquirido los derecho 
de su desarrollo, 

separación de la forma y el contenido: el principio según el cual uno 
debería representar por separado la esencia de un documento y el 
estilo con el que se presenta. Un elemento de mi decisión de usar 
el SGML y un importante elemento de la mejora de accesibilidad 
del Web. 

servidor: un programa que proporciona un servicio (generalmente in- 
formación) a otro programa, llamado cliente. Un servidor web tie- 
ne páginas web y permite a los clientes leer y escribir en ellas. 
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SGML (Standard Generalized Markup Language) [Lenguaje Markup 
Estándar Generalizado]: un estándar internacional de lenguajes 
markup, una base del HTML y un precursor del XML. 

SMIL (Synchronized Multimedia Integration Language) [Lenguaje de 
Integración Sincronizado Multimedia]: un lenguaje para crear una 
presentación multimedia especificando las relaciones espaciales y 
temporales entre sus componentes. Una recomendación W3C. 

SVG (Scalable Vector Graphics) [Gráficos de Vector Escalable]: un 
lenguaje que describe dibujos en términos de las formas que los 
componen, de modo que puedan reproducirse lo mejor posible. 

Tangle: un programa que escribí para jugar con el concepto de infor- 
mación como algo consistente sólo en las conexiones. 

TCP (Transmission Control Protocol) [Protocolo de Transmisión de 
Control]: un protocolo de ordenador que permite a un ordenador 
enviar a otro una corriente continua de información rompiéndola 
en paquetes y recomponiéndola al otro extremo, reenviando cual- 
quier paquete que se haya perdido en Internet. El TCP usa IP 
para enviar los paquetes, y a los dos se les llama TCP/TP. 

Universidad Keio: cerca de Tokio, Japón. Colaborador de W3C. 

URI (Universal Resource Identifier) [Identificador Universal de Re- 
cursos]: el conjunto de letras (que a menudo empieza con http://). 
que se usa para identificar cualquier cosa en el Web. 

URL (Uniform Resource Locator) [Localizador Uniforme de Recur- 
sos]: un término usado a veces para ciertos URIs para indicar que 
pueden cambiar. 

vínculo: una referencia de un documento a otro (vínculo externo), o 
de un lugar del mismo documento a otro (vínculo interno), que se 
puede seguir de manera eficiente con un ordenador. Es la unidad 
de conexión del hipertexto. 

Viola: un lenguaje de ordenador interpretado (como Java) desarrolla- 
do por Pei Wei en la Universidad de Berkeley. También es un na- 
vegador web hecho usando Viola. 

VRML (Virtual Reality Modeling Language) [Lenguaje Modelador de 
Realidad Virtuall: una idea para gráficos compuestos en 3D en el 
Web propuesta por Dave Raggett como “lenguaje Markup de Rea- 
lidad Virtual” y establecido por Mark Pesce como variante del for- 
mato “Inventor” de Silicon Graphics; más tarde gestionado por el 
consorcio VRML, que actualmente es el consorcio “Web 3D”. 
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W3C (World Wide Web Consortium): una agrupación neutral de 
aquellos que se preocupan por el Web, con la misión de conducir 
al Web a su máximo potencial. 

WAI (Web Accesibility Initiative) [Iniciativa de Accesibilidad al 
Web]: un dominio de W3C que trata de asegurar el uso del Web 
por parte de cualquiera, aunque esté discapacitado. 

WAIS (Wide Area Information Servers) [Servidores de Información 
de Zona Amplia]: un sistema de información distribuida diseñada 

por Brewster Kahle cuando estaba en Thinking Machines. WAIS 
era como un Web de buscadores, pero sin el hipertexto. 

Web: abreviatura de World Wide Web. 

Web Semántico: el Web de datos con significado en el sentido de que 
un programa de ordenador pueda aprender lo bastante acerca de 
lo que quieren decir los datos como para procesarlos. 

World Wide Web (tres palabras; también conocida como WWW): el 
conjunto de toda la información accesible mediante el uso de or- 
denadores y redes. Cada unidad de información se identifica por 
medio de un URI. 

WorldWideWeb (una palabra, sin espacios): el nombre del primer 
cliente web, un navegador/editor que funcionaba en un aparato 
NeXT. 

X: el sistema X Window, inventado por Bob Scheifler; un interface es- 
tándar entre un programa y una pantalla que eran omnipresentes 
en los sistemas Unix. Contrariamente al Windows de Microsoft, 
desde el principio X permitía a los programas que funcionaban en 
un aparato aparecer en otro, a través de Internet, Scheifler dirigió 
el X Consortium para el MIT/LCS durante muchos años; después 
lo acabó cerrando. 

Xanadu: un proyecto de hipertexto global planeado por Ted Nelson. 

XML (Extensible Markup Language) [Lenguaje Markup Extensi- 
ble]: un sucesor simplificado del SGML. El lenguaje genérico de 
W3C para crear nuevos lenguajes markup. Los lenguajes markup 
(como el HTML) se usan para representar documentos con una 
estructura en forma de árbol. El XML es un producto de W3C y 
una marca registrada del MIT. 

XSL (Extensible Style Sheet Language) [Lenguaje de Hoja de Estilo 
Extensible]: un lenguaje de hoja de estilo, comoel CSS, pero que 
también permite la transformación de documentos. 
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ElWodg Wide Web ha cambiado 
para siempre:la condición de la 
vida moderna, alterando la forma 

gocios, el ocio, la infor 
a creación de comunidades 
y el intercambio de ideas. 

Tim Berners-Lee, el inventor 
dei World Wide Web, nos descubre 
en este libro.el origen de la Reg, 
desde su revolucionaria intro- 
ducción y la creación de las siglas 
WWW y HTTP, hasta su opinión 
sobre el futuro desarrollo de este 
medio revolucionario. 


Las reflexiones de Berners-Lee 

guien nunca se ha beneficiado 

nalmente del Web= pueden ayudar a los lectores a entender 
2sntica naturaleza de la Red, permitiéndoles usarla con el 
o aprovechamiento. Expone sus puntos de vista acerca 
s de tanta importancia como son la censura, la privacidad, 
nte poder de las compañías de software en el mundo 


la necesidad de encontrar el equilibrio ideal entre las 

ciales y comerciales en el World Wide Web. Las incisivas 
Fealiza al estado actual de la Red poñen de manifiesto 
eda mucho por hacer. Finalmente, Berners-Lee nos 
j ¿propio plan para el futuro del Web, un plan que 
apoyo y la participación activos de programadores, 
de ordenadores y organizaciones sociales para que 
Ése a cabo. 
riers-Lee es director del Consorcio World Wide Web, 
de coordina el desarrollo del World Wide Web, y trabaja 
atorío de Ciencias Informáticas del MIT. Ha recibido 
Sremios, entre ellos el prestigioso MacArthur Fellowship 
te en Cambridge, Massachusetts. 


